Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

[Ben Schwartz <[e-mail]>]

On Fri, Sep 11, 2020 at 7:53 AM tirumal reddy <[e-mail]> wrote:

> On Fri, 11 Sep 2020 at 16:11, Nick Lamb <[e-mail]> wrote:
>
>> On Fri, 11 Sep 2020 12:32:03 +0530
>> tirumal reddy <[e-mail]> wrote:
>>
>> > The MUD URL is encrypted and shared only with the authorized
>> > components in the network. An  attacker cannot read the MUD URL and
>> > identify the IoT device. Otherwise, it provides the attacker with
>> > guidance on what vulnerabilities may be present on the IoT device.
>>
>> RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
>> over LLDP without - so far as I was able to see - any mechanism by which
>> it should be meaningfully "encrypted" as to prevent an attacker on your
>> network from reading it.
>>
>
> RFC 8520 allows other means (see sections 1.5 and 1.8) like 802.1X (for
> example, TEAP (it does not allow TLS cipher suites without encryption).
> The client identity (certificate carrying the MUD URL) is encrypted and not
> visible to eavesdroppers. Further, RFC8520 discusses IoT devices may not
> even omit the URL. It recommends to use a proxy to retrieve the MUD file
> for privacy reasons.
>

These protections are difficult to deploy (representing a minority of
devices), and do not appear to change the dynamic significantly, given the
draft's assumption that the IoT device has already been compromised.  If
the malware can read the MUD URL out of the IoT device's local storage, or
any unit of this model ever contacts an attacker-controlled MUD Manager,
the attacker can access the MUD file, monitor it for updates, etc.

This design treats the MUD file as a "widely shared secret", which is a
fragile arrangement.  It does not appear to match the main conceptual model
of MUD, which describes MUD files as being "published", i.e. generally
public.

I also think this proposal is likely to seriously impede the ability of IoT
vendors to adopt new versions of TLS, or new protocols such as QUIC.  Such
updates would be delayed by (1) the need to add entries to this YANG model,
and then (2) the time for MUD gateways to develop and deploy the new
entries.  Delaying protocol upgrades reduces security, contrary to the
goals of this draft.