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

[Ben Schwartz <[e-mail]>]

On Mon, Sep 14, 2020 at 11:09 AM Eliot Lear <lear=[e-mail]>
wrote:

> Hi Ben,
>
> Much of this relitigates RFC 8520, but IMHO it is worth reviewing
> assumptions from time to time.  Remember, the purpose of MUD is to identify
> an authorization profile for a device to a network so that either access
> can be granted based on that profile or an anomaly can be detected.  The
> primary, but not exclusive, focus is on IOT.
>
> Please see below.
>
>
> 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.
>
>
>
> We should separate the MUD URL from the MUD file.  The MUD file is
> absolutely 100% public, and consists of information that is observable –
> or should be observable – from the device.  So if you are a Meddler In The
> Middle (;-) (MITM) you get this information *anyway*.
>

Agreed ... but this proposal appears to be predicated on a contrary
assumption.  It assumes that it is difficult for malware to learn the TLS
profile of the device, and then proceeds to place this profile information
in the (public) MUD file, where malware can easily retrieve it.

The MUD URL gives up device type information.  This is different in
> character, but *often* but not *always* easily gotten.  I would say that
> if a manufacturer is taking steps to prevent fingerprinting, then they
> should take steps to protect the MUD URL.  That’s an active area of
> interest for some.
>
>
> 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.
>
>
> One can deploy a MUD file update in advance of a code update.  The latter
> takes a whole lot longer than the former.  No IoT manufacturer is going to
> put out something in less than the default time of 48 hours, lest they
> brick millions of devices.
>

I'm not thinking of the hours-days timescale of MUD file updates; I'm
thinking of the months-years timescale of updating standards to support new
features.  How long does a device have to wait after a new protocol
revision comes out before it can start using the new protocol?  First,
we'll need a new draft to update this YANG model with parameters for the
new protocol.  Then, we'll need all the world's MUD vendors to write new
firmware that can parse the new protocol and compare it to the model.  Then
we'll need all the MUD gateways to update to the new firmware.

Of course, the device can unilaterally "back out" of this arrangement by
issuing a reduced MUD file, but if this feature is advertised to customers,
transitioning to a new protocol may not be an option for many years.
(Consider, for example, the impact on QUIC deployment.)

 Is this more work for an IoT manufacturer?  Sure.  One thing the draft
> might do is discuss how to incorporate something into unit testing to write
> out the change.
>
> Eliot
>
>
>