To: adrian@olddog.co.uk, rtg-ads@ietf.org
Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org
References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk>
 <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com>
 <022901d3536d$d01d7b10$70587130$@olddog.co.uk>
From: Eliot Lear <lear@cisco.com>
Message-ID: <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com>
Date: Thu, 2 Nov 2017 09:46:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0)
 Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <022901d3536d$d01d7b10$70587130$@olddog.co.uk>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/vPp1eaW5AOyWG-8KtuvccW1ToKg>
Subject: Re: [RTG-DIR] RTG-DIR review of draft-ietf-opsawg-mud-13
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID
Content-Type: multipart/mixed; boundary="THoqLSCOu4COKf0mml9UH2EslJFO3lqsx";
 protected-headers="v1"
From: Eliot Lear <lear@cisco.com>
To: adrian@olddog.co.uk, rtg-ads@ietf.org
Cc: draft-ietf-opsawg-mud@ietf.org, ietf@ietf.org, rtg-dir@ietf.org
Message-ID: <44f7279c-aef8-b8ab-dfb5-a941f52e7899@cisco.com>
Subject: Re: RTG-DIR review of draft-ietf-opsawg-mud-13
References: <01d501d35342$b90d7450$2b285cf0$@olddog.co.uk>
 <5f1c796d-3700-cda3-0bce-f5c6e70ffc9a@cisco.com>
 <022901d3536d$d01d7b10$70587130$@olddog.co.uk>
In-Reply-To: <022901d3536d$d01d7b10$70587130$@olddog.co.uk>

--THoqLSCOu4COKf0mml9UH2EslJFO3lqsx
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US

Hi Adrian,


On 11/2/17 1:01 AM, Adrian Farrel wrote:
> This looks really good, Eliot. Thanks for being so responsive and posit=
ive 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 tha=
t the default
>>> will be that devices are MUD-enabled (good) and that users will not b=
e
>>> 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-enab=
led).
>>> More burble below, but it seems to me that we should make privacy-sup=
porting
>>> modes of operation at least the default, but possibly the only approa=
ch.
>>>
>>> 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 ha=
ve
>>> 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 ho=
pe
>> 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 var=
iety
>> 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 concern=
s,
>> while others will have quite a few.  In addition, whatever capabilitie=
s the
>> device has must intersect the capabilities found in deployments.
>>
>> With all that in mind, what I propose is the following:
>> =E2=80=A2 Add text that RECOMMENDs that devices make use of TEAP when =
there
>>     may be privacy concerns and when it is available; and
>> =E2=80=A2 In other cases where privacy may be a concern, we should REC=
OMMEND
>>    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=
=2E
> 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.=C2=A0 It's not perfect but w=
ould
address the point you make above.

> Of course, when the MUD controller is remote (the mobile case), it's al=
l 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 th=
at will be implemented and so make the world a somewhat better place. But=
 just recall that someone implemented those devices that "leak like sieve=
s" 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.=C2=A0 My guess is that the same who are unlikely to heed such a
recommendation are also highly unlikely to implement MUD in the first pla=
ce.

>
> Well, I'm not in a position to block the whole effort, and I'm not enou=
gh of an expert to suggest a solution to my concern that works for all ty=
pes 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.=C2=A0 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 in=
fo.
>>> 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 th=
ing
>> through one level of indirection.  That doesn't require any specific c=
hange
>> to the URL itself.  I've included some text in response to Mark, but t=
hat
>> 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 someth=
ing for it to be right :-)
>
> So long as it is possible for the MUD Controller to be in one locale an=
d 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 21=
19 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/assu=
mption.
>
> 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.=C2=A0 The use of passive in this c=
ase
is appropriate because the assumption is general and not attached to a
single party.=C2=A0 Also, the following phrase =E2=80=93 and the rest of =
the document
=E2=80=93 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 cl=
assified.

Means of classification?

Eliot



--THoqLSCOu4COKf0mml9UH2EslJFO3lqsx--

--HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJZ+ttQAAoJEIe2a0bZ0nozDdMIAJV3mFDhMVhjRPWEroPyK9yx
e0pWfTWboTow4jcOkNJrMl7wZ2avp86sbmA1qw8TAfR6dVm0TSfBvhi23c9ixc1y
MQKRL4FG8I6QzvL/GG8r06hihDQmPsmi1pL4O3Z/tyAc2UlzSeFa9pWOUy7o/d0J
+DixpL9Z0amg2hPXsqljrveA/9TyEQM1TaeZ1vtWL4mtlk43Fo61sQUlwhH/uFjS
zWa/31hQTbtAfmN4BHGBZ3aTk8PgnoPU+ROf1RP3pWnbnmjWaf0KE+PI5V9WpixS
bO2wi2f5xAeKkYo4ioJ4SMX6DMdsq6zKZMS1bMDWSqDgmwpc7MYNsgFtDVVnPkA=
=Eq7T
-----END PGP SIGNATURE-----

--HEOxsNcAnkXKsqEoJd8GewcDbWwqEGnID--