Subject: [Mud] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt

From: tirumal reddy <[email-masked]>
Date: Thu, 16 Jan 2020 19:13:20 +0530

Hi all,

This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02
updates the draft to discuss privacy enhancing technologies and evasion
techniques used by malware, visibility into TLS 1.3 parameters and how
certain types of malware can be blocked without acting as a (D)TLS 1.3
proxy.

As a reminder, this draft extends Manufacturer Usage Description (MUD) to
incorporate (D)TLS profile parameters.  This allows a network element to
identify unexpected (D)TLS usage, which can indicate the presence of
unauthorized software or malware on an IoT device.

Comments and suggestions are more than welcome.

Cheers,

-Tiru

On Thu, 16 Jan 2020 at 18:58, tirumal reddy <[email-masked]> wrote:

---------- Forwarded message ---------
From: <[email-masked]>
Date: Thu, 16 Jan 2020 at 18:44
Subject: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt
To: Tirumaleswar Reddy.K <[email-masked]>, Dan Wing <[email-masked]>,
Blake Anderson <[email-masked]>

A new version of I-D, draft-reddy-opsawg-mud-tls-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:           draft-reddy-opsawg-mud-tls
Revision:       02
Title:          MUD (D)TLS profiles for IoT devices
Document date:  2020-01-16
Group:          Individual Submission
Pages:          19
URL:
https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-02.txt
Status:         https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:       https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02
Htmlized:
https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:
https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-02

Abstract:
   This memo extends Manufacturer Usage Description (MUD) to incorporate
   (D)TLS profile parameters.  This allows a network element to identify
   unexpected (D)TLS usage, which can indicate the presence of
   unauthorized software or malware on an endpoint.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Michael Richardson <[email-masked]>
Date: Tue, 21 Jan 2020 20:03:05 -0500

draft-reddy-opsawg-mud-tls-02 proposes to describe TLS profile options in a
MUD file in order to help middle boxes (Intrusion Detection Systems) to
identify malware.

I wrote an email about issues related to the idea, but this email is about
the way in which MUD files become trusted, and how they should be updated.

Michael Richardson <[email-masked]> wrote:
    > I see two advantages of this work, which mitigates my concern slightly.
    > (but, only slightly)
    > 1) if it's gonna get done by IDS vendors, then IoT device manufacturers
    > might as well provide a way to help them *get it right*

A tussle that I thought I put into a document, but it seems that I did not
yet do that, is whether to update the MUD URL to a firmware specific value,
or whether to update the MUD file place.

I thought I was going to cover that in draft-richardson-opsawg-securehomegateway-mud-02
and I said so in the introduction, and I thought I decided that was a poor
place to put that discussion, and I wrote some text in some document, but it
seems that was a delusion :-)

I guess I wrote this in email to mud@ actually.

The issue is that if you update the MUD file in place without changing the
URL then it will apply to older firmware revisions as well as new ones.

If a vendor is going to put very specific information relating to TLS
libraries into a MUD file, then it is going to be critical that any updates
to the firmware (such as BUG FIXES) result in updates to the MUD TLS profile.

Updating the URL that the firmware emits via DHCP or LLDP is relatively easy,
but not very secure.   An IDS system should *not* trust updates to that URL
as malware could trivially update the URL as well.

But, updating the URL in IDevID is difficult to do. Quite reasonably it might
be impossible without a device recall.  The IDevID version is much easier to
invest trust into.  And it clearly links back to the manufacturer.

If relatively ephemeral things like a TLS profile are going to go into a MUD
file, then I think that we need to think again about the update issue.

[this draft sits in outbox for a week]

I've now written:
  https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-acceptable-urls/

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 22 Jan 2020 08:31:58 +0100

Hi mud'ler,

> invest trust into.  And it clearly links back to the manufacturer.

This is one of the biggest issues that came to my mind ad-hoc. Is 
changing the URI really an option? I would assume this type of 
encapsulation is trustworthy, I think.

> to the firmware (such as BUG FIXES) result in updates to the MUD TLS profile.

Hm. I always assumed that either a MUD file or the parameters to a MUD 
URI would take care of "versions" or "composition" of the requester (so 
the requester appends information about that in the URI). Is that not 
how other people think about it? The idea of a canonical composition of 
the segments in the URI did not fly IIRC (due to rfc7320 I assume).

Viele Grüße,

Henk

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jan 2020 12:21:27 -0500

> This is one of the biggest issues that came to my mind ad-hoc. Is changing
    > the URI really an option? I would assume this type of encapsulation is
    > trustworthy, I think.

Changing the URI in an IDevID is not, in my opinion, feasible.
While I can imagine ways for an IDevID to be renewed online, I would prefer
that it be buried so deep into the TPM that it can't be changed in the field.

    > Hm. I always assumed that either a MUD file or the parameters to a MUD URI
    > would take care of "versions" or "composition" of the requester (so the
    > requester appends information about that in the URI). Is that not how other
    > people think about it? The idea of a canonical composition of the segments in
    > the URI did not fly IIRC (due to rfc7320 I assume).

Yes, so I assume that the MUD URL will depend upon the firmware version.
In  draft-richardson-opsawg-mud-acceptable-urls-00 I am proposing something
like:
    IDevID MUD URL https://www.example.com/mud/frobits/modelT/base.json
    DHCP MUD URL   https://www.example.com/mud/frobits/modelT/build1176.json

The base.json -> build1176.json transition is either *implicit*, only the
last part can change.  Or we introduce a mud-base-url attribute to the
base.json file.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 22 Jan 2020 13:31:39 -0500

> that it be buried so deep into the TPM that it can't be changed in the field.

I  see some words to the contrary in
https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-00

i.e. I see the following:

"The DHCP and LLDP mechanisms are not signed, but are asserted by the device. "

Why can't the MUD URL emitted by the device using DHCP be signed with
the device private key?

If the IDevID for the device can be sent to the MUD Controller using a
trusted agent  then the
Device can just send a signed MUD URL in the DHCP request (or LLDP),.

With this mechanism, it may not be necessary to imbed the MUD  URL in
the device certificate
and the device can freely change the MUD URL with firmware updates.

Onboarding mechanisms (e.g. DPP) can be used to authenticate the
device against the certificate.

With this setup, it is not necessary to include the MUD URL as part of
the device certificate.

Am I missing something obvious.

>
> --
> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud

-- 
M. Ranganathan

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 22 Jan 2020 20:07:27 +0100

> Am I missing something obvious.

No, not at all. I am not aware of potential procedural caveats and in 
principle this sounds fine. Alas, now the "trust in the MUD URL" relies 
on the protection of the private key. If that key is not 
shielded/isolated properly and the integrity of the devices is 
compromised, the trustworthiness of the MUD URL is gone without any 
indications, consecutively. Please mind, maybe I am the one missing 
something now.

The burden of providing evidence about the "trust in the MUD URL" lies 
with the device in this scenario.

If you embed it in the device's DevID, this burden is with the trust 
anchor, I think. Although a complementary entity is required to 
remediate loss of device integrity, still (as in most cases). A 
compromised device alone can and will use any MUD URL it wants.

Maybe I am over-simplifying my point, but I think that is one main 
difference. Analogously, I am still not convinced that changing the MUD 
URL is not dangerous in principle.

If you do not allow for a MUD URL to change, you avoid a lot of 
complexity. The simplicity of MUD is one of its main selling points.

Viele Grüße,

Henk

On 22.01.20 19:31, M. Ranganathan wrote:
> "The DHCP and LLDP mechanisms are not signed, but are asserted by the device."
>

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Jan 2020 21:12:28 +0100

> On 22 Jan 2020, at 08:31, Henk Birkholz <[email-masked]> wrote:
> 
> Hi mud'ler,
> 
> This is one of the biggest issues that came to my mind ad-hoc. Is changing the URI really an option? I would assume this type of encapsulation is trustworthy, I think.

To me this is something that TEEs can really assist with, but we may need to think about how the URL is communicated.  Should it be in an idevid long term or in some other signed object?

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jan 2020 16:35:08 -0500

M. Ranganathan <[email-masked]> wrote:
    >> Henk Birkholz <[email-masked]> wrote: > On 22.01.20
    >> 02:03, Michael Richardson wrote: >> But, updating the URL in IDevID is
    >> difficult to do. Quite reasonably it might >> be impossible without a
    >> device recall.  The IDevID version is much easier to >> invest trust
    >> into.  And it clearly links back to the manufacturer.
    >> 
    >> changing > the URI really an option? I would assume this type of
    >> encapsulation is > trustworthy, I think.
    >> 
    >> Changing the URI in an IDevID is not, in my opinion, feasible.  While
    >> I can imagine ways for an IDevID to be renewed online, I would prefer

    > Why can't the MUD URL emitted by the device using DHCP be signed with

It could be. Bud:
a) we haven't defined the MUD DHCP extension that way.  We could probably
   sign the entire DHCP request with RFC3110. I've done this in the distant past.

b) it doesn't gain us anything. It's not a signature from an IDevID (or
   LDevID) that is interesting.  The malware, having taken over the device
   could do that. That could be as easy, on a *nix machine, as dropping
   a file into /etc/dhclient.d/ with the new MUD URL, and the DHCP
   mechanism would sign it for you.

What we want is a signature from the manufacturer, or possibly, as Eliot
suggests, from a TEE/TPM.   But, how does it know what the MUD URL for this
firmware is?   And, if you've got all that, then you have remote attestation
anyway, so why not just have the RATS Verifier provide the MUD URL as part
of the Attestation Results?

Since remote attestation is not going to be common case for home appliances
in the near future (not because the devices are incapable, but because the
homes are ill-equipped [%]), what we can do do today to easily keep the
MUD URL from changing too much, without locking it down completely?

[%] - the lack of equipment to do remote attestation also means that
    probably also has no secure controller to do onboarding, or evaluate the
    IDevID.   So, MUD will be TOFU.

Henk Birkholz <[email-masked]> wrote:
    Henk> If you do not allow for a MUD URL to change, you avoid a lot of
    Henk> complexity. The simplicity of MUD is one of its main selling
    Henk> points.

Eliot had previously convinced me that updating the MUD file in place was
probably workable, and this was not that big a deal.  
The TLS profile convinces me otherwise.
The need to pin the manufacturer signature probably deals with a lot of the
changes that we might need.

    >> encapsulation is trustworthy, I think.

    Eliot> To me this is something that TEEs can really assist with, but we
    Eliot> may need to think about how the URL is communicated.  Should it be
    Eliot> in an idevid long term or in some other signed object?

I think that you really mean a TPM-enabled secureboot environment, which a
TEE can implement.   If the firmware (update) comes with a signed blob that
the boot environment can interpret, then that could also contain a
manufacturer signed URL.  
The SUIT manifest pretty much satisfies this requirement, but we still need a
signed thing to put into a DHCP (or LLDP) package.  That would likely need to
be a simple CoseSign0 object.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 22 Jan 2020 21:33:20 -0500

If a device provides a MUD URL which points to a 404, what does that mean?
Section 1.6 says that it should tolerate failures for awhile.

I am thinking about a case where malware discovers that a particular version
of firmware has a MUD file that contains an error that allows for exploit
traffic.

Can a manufacturer just remove a MUD file from their web site if the firmware
revision is obsolete?  That seems wrong.

It seems that it ought to just post an "empty" (no ACLs) mud file in that
case.  But, then we wind up with a bunch of tombstones.

Maybe the file could have something assertive, like: "bad bad, do not run,
quarantine now" as flag?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2020 21:48:48 -0500

> case.  But, then we wind up with a bunch of tombstones.

Why is that bad?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jan 2020 00:38:44 -0500

> Why is that bad?

It's not bad in of itself, except that sometimes clutter gets cleaned up.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 23 Jan 2020 08:48:58 +0100

Hi Michael,

> On 23 Jan 2020, at 03:33, Michael Richardson <[email-masked]> wrote:
> 
> 

If the MUD file itself contains an error that overexposes a vulnerable device, it seems to me that the proper course of action is simply to post a correction that will get picked up sometime after the cache-validity period expires.

As to your other question: what if the MUD file can’t be reached?  The general answer is simple: keep doing what you were doing.  Don’t change policies because you can’t get to the mud file server.  That’s just asking for a boot to the head.  If the device never had a MUD file, you would have some default handling.  If it already had a mud file, then you have some policy to go with.

So suppose the device has a bad mud file, and the attacker tries to block the file server.  At that point, the device is vulnerable, but the fact that the file is not accessible, particularly if it is not accessible for some period of time, is probably something that is worthy of attention.  Did it become unavailable because of an attack, or did it become unavailable because the maker went out of business?

Is it the administrator or the mud file manager that should attend to this?  Could be either, but over the long run you would rather it be the latter, with some back end support.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Jan 2020 11:47:16 -0500

> If the MUD file itself contains an error that overexposes a vulnerable
    > device, it seems to me that the proper course of action is simply to
    > post a correction that will get picked up sometime after the
    > cache-validity period expires.

Assume that it's not the file itself that is broken, but the firmware that
references it.  That is, version N of the firmware is bad, and it references
mud file example.com/revN.json.

How does the manufacturer indicate to the MUD controller that, if you have
revN, that you want it offline.

    > As to your other question: what if the MUD file can’t be reached?  The
    > general answer is simple: keep doing what you were doing.  Don’t change
    > policies because you can’t get to the mud file server.  That’s just
    > asking for a boot to the head.  If the device never had a MUD file, you
    > would have some default handling.  If it already had a mud file, then
    > you have some policy to go with.

Agreed, we should not change behaviour if the file is gone.

The question is, is there a path which leads to the MUD controller
abandonning the file?