Hi Adrian, On 11/2/17 1:01 AM, Adrian Farrel wrote: > This looks really good, Eliot. Thanks for being so responsive and positive to my peculiar brand of paranoia and pedantry. Not at all, and thanks for improving the work. > Just a few bits of discussion remain... > >>> I know I ranted about privacy before and the authors took some text I wrote >>> as the basis of the privacy considerations, but I'm still worried that the default >>> will be that devices are MUD-enabled (good) and that users will not be >>> protected. It would be sad if the user's only option is to reject MUD devices >>> (especially as they might not even know that the devices are MUD-enabled). >>> More burble below, but it seems to me that we should make privacy-supporting >>> modes of operation at least the default, but possibly the only approach. >>> >>> Section 15 has... >>> >>> The release of a MUD URL by a Thing reveals what the Thing is, and >>> provides an attacker with guidance on what vulnerabilities may be >>> present. >>> >>> Pleased to see this text: it was a security concern I had. Good to have >>> it flagged. However, the mitigation suggested 2 paragraphs later is a >>> bit thin and sounds rather optional. I see how an implementer might >>> take action, but what can a user do to protect their device? [...] >> While this may not be a *perfect* solve for all of your concerns, I hope >> you will find the proposal below Good Enough. Keep in mind that we >> are attempting to address a very broad set of devices with a large variety >> of capabilities, from energy-harvesting devices that may never encrypt >> (think a wall switch) to devices that have heaps of power and memory >> (think robots). Many of the devices have very limited privacy concerns, >> while others will have quite a few. In addition, whatever capabilities the >> device has must intersect the capabilities found in deployments. >> >> With all that in mind, what I propose is the following: >> • Add text that RECOMMENDs that devices make use of TEAP when there >> may be privacy concerns and when it is available; and >> • In other cases where privacy may be a concern, we should RECOMMEND >> that a configuration option be provided, particularly when devices are >> designed to be mobile, which is where I think most of your concerns >> stem from. > This is getting gooder. Thanks. > Even when the MUD controller is on the premises (the not mobile case), it contacts > an offsite file server, and that act is visible. > Suppose my Hi-Fi uses MUD - now you know that my house is worth robbing. > Suppose my intruder alarm uses MUD - now you know what security system I have. Here, I think you have some cause for hope, because on the whole, in the home, wireless encryption is generally used. It's not perfect but would address the point you make above. > Of course, when the MUD controller is remote (the mobile case), it's all even more worrying. Yes, and to that end I propose to highlight a particular warning for open networks (this would be one amongst many that developers should heed with regard to open networks). > > I know you are trying to trade between perfect and getting something that will be implemented and so make the world a somewhat better place. But just recall that someone implemented those devices that "leak like sieves" and those folk are unlikely to see a Recommendation as anything like a strong hint. My hope is that this problem will abate over time, but I really cannot say. My guess is that the same who are unlikely to heed such a recommendation are also highly unlikely to implement MUD in the first place. > > Well, I'm not in a position to block the whole effort, and I'm not enough of an expert to suggest a solution to my concern that works for all types of device. > >>> There seems to be some overlap of terms and definitions in 1.5 and 1.6. >> Can you be more specific? > 1.5 and 1.6 both have "manufacturer". > 1.5 has "controller" and 1.6 has "MUD controller". > The definitions don't match. Ah- that is because they are being used in different contexts. One is intended as a YANG node and the other really means those people who build the thing. > >>> 3.5 has me confused. Looks like a fine idea, but how does it work? A >>> Thing reports the MUD URL, and the file that is pulled contains the >>> systeminfo URL, and the info that is pulled contains the localised info. >>> Have I got that right? >> Yes. >> >>> That means that the MUD URL has to include the correct systeminfo for >>> the locality. Presumably we're interested in the locality of the MUD >>> controller. >> The intent here is basically to allow for language tags to do their thing >> through one level of indirection. That doesn't require any specific change >> to the URL itself. I've included some text in response to Mark, but that >> text may further shift based on other suggestions Mark may have. > I'm missing something, but that's OK, I don't have to understand something for it to be right :-) > > So long as it is possible for the MUD Controller to be in one locale and the MUD Server in another and all the bits to work right, I'm happy. > >>> Introduction >>> >>> Please do NOT use random uppercase words in your text. There's NO >>> need: the readers are no more stupid than the average reader of an >>> RFC. >>> >>> Ditto 3.4, 3.6 >> Sorry- I didn't parse this. > Sorry I'm being sassy. > > I mean, please don't capitalise for emphasis. Just limit yourself to 2119 capitalisation. Got it. > >>> Introduction >>> >>> The key points are that the device itself is expected >>> to serve a limited purpose, >>> >>> I think you mean s/expected/intended/ >> How about "assumed"? > We're both being overly passive. Who has the expectation/intention/assumption. > > By "intended" I meant "intended by the manufacturer". > So, actually, any one of the three words is fine, if you can attribute the verb to someone. Ok, I think we might have to disagree. The use of passive in this case is appropriate because the assumption is general and not attached to a single party. Also, the following phrase – and the rest of the document – make clear who is doing what. > >>> Introduction >>> >>> o A classifier that a device emits that can be used to locate a >>> description; >>> >>> Classifier or classification? >> Classifier. > Oh. > > A "classifier" is a person or thing that classifies. > I don't think the device emits a thing or a person :-) > I think it emits a piece of information that allows the device to be classified. Means of classification? Eliot
Attachment:
signature.asc
Description: OpenPGP digital signature