Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13

[Eliot Lear <[e-mail]>]

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