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

From: tirumal reddy <[email-masked]>
Date: Thu, 16 Jan 2020 18:58:02 +0530

---------- 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: tirumal reddy <[email-masked]>
Date: Thu, 16 Jan 2020 19:05:31 +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 endpoint.

Comments and suggestions are more than welcome.

Cheers,

-Tiru

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

> Status:
> https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jan 2020 21:27:40 -0500

tirumal reddy <[email-masked]> wrote:
    > 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 endpoint.

I have read opsawg-mud-tls, and I am in general very very reluctant to
provide detailed instructions on doing innovation kill intrusive DPI.
I think that it will ultimately not result in any improvements to network
security.

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*
   2) it seems that manufacturers might be able to say, "HANDS OFF"
      to IDS systems. (perhaps avoiding use of more colourful language)

The document says:
   In other words, malware developers will
   have to develop malicious agents per IoT device type, manufacturer
   and model, infect the device with the tailored malware agent and will
   have keep up with updates to the device's (D)TLS profile parameters
   over time.  Further, the malware's command and control server
   certificates need to be signed by the same certifying authorities
   trusted by the IoT devices.  Typically, IoT devices have an
   infrastructure that supports a rapid deployment of updates, and
   malware agents will have a near-impossible task of similarly
   deploying updates and continuing to mimic the TLS behavior of the IoT
   device it has infected.

It seems to me that malware will know exactly, thanks to this extension how
to perfectly impersonate the device.  Given that TLS1.3 makes so many of the
characteristics of the implementation less visible, it seems that this is
just a dangerous arms race.  As border MUD gateways get more detailed in the
way they examine things, the ability to innovate in TLS will simply diminish.
It is my understand that we already had to do the TLS 1.3 version negotiation
differently thanks to middle boxes because of such nonsense.

I don't think that section 4.1 needs to explain how BRSKI works.
In any case, it's not BRSKI that matters, but EST(RFC7030)'s /cacerts.
I see that it's probably difficult to get to RFC7030 just to run /cacerts,
but if BRSKI is being used already.  {If this gets better IoT onboarding into
Enterprises.... well. What a Faustian bargin...}

I believe that attempting to auto-configure a TLS 1.3 MITM proxy using EST is
a really bad idea.  Devices that are willing to fall prey to such a
"friendly-fire" attack would seem to be broken to me, period.
I suspect that US HIPAA legislation and probably European GDRP might well
make such a MITM a serious privacy violation.  Any medical device that communicates
patient data that could be spoofed like this might be considered to be violating.

Additional, it is entirely reasonable (perhaps, given MITM attacks!) for an IoT
device manufacturer to "call home" using a baked in, non-public, trust
anchor. Such a situation would be indiguishable from malware calling C&C
using a baked-in trust anchor.
I would certainly want to do this for firmware updates.

Given that MUD can clearly control where connections are made, it seems to
me that much of this effort is a mis-guided relic of pre-MUD DPI IDS systems.

I suggest that section 4.2 reference draft-richardson-opsawg-mud-iot-dns-considerations-01.

I didn't understand the purpose of the SPKI pin info mentioned in section 5.
I suggest that you remove details from this overview section, and list just
the high-level and leave the details for a section on each part.

As far as I can tell from the YANG module and the example, the stated TLS
profile appears to apply to any/all TLS traffic coming from the device.
I would have expected it to be expressed on a per-port outgoing/incoming basis.
(Perhaps defining the profile(s) once and then re-using it)

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

---

From: tirumal reddy <[email-masked]>
Date: Tue, 21 Jan 2020 18:36:14 +0530

Hi Michael,

Thanks for the review. Please see inline

> I think that it will ultimately not result in any improvements to network

No, the proposed mechanism will help identify the presence of unauthorized
software or malware on an IoT device.
MUD is not suitable for IoT devices with broad communication patterns and TLS
profile parameters can be used on such devices to permit intended TLS use
and block malicious TLS use.

Middleboxes act as TLS proxies in several deployments and the behavior of a
compliant TLS 1.3 proxy is discussed in Section 9.3 of
https://tools.ietf.org/html/rfc8446. Most importantly, network security
services have been using TLS profile parameters to successfully identify
malware and benign flows for several years (for example, see
https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise-networks/enterprise-network-security/nb-09-encrytd-traf-anlytcs-wp-cte-en.pdf
).

We have profiled several IoT devices in our lab and also observed TLS
profile parameters of thousands of malware flows. Our analysis helped
conclude intended TLS use can be permitted and malicious TLS can be blocked
(see
https://datatracker.ietf.org/meeting/106/materials/slides-106-opsawg-draft-reddy-opsawg-mud-tls
(slides
7 to 15) for more details).

>       to IDS systems. (perhaps avoiding use of more colourful language)

Network security vendors offering firewalls/IPS to enterprise networks
already have the capability of performing TLS handshake inspection and
acting as a TLS proxy, they can leverage the proposed mechanism. Further,
firewalls acting as TLS proxy do several checks to identify MiTM attack.
For example, the most recent one is the Microsoft vulnerability to validate
certificates
https://media.defense.gov/2020/Jan/14/2002234275/-1/-1/0/CSA-WINDOWS-10-CRYPT-LIB-20190114.PDF;
middle boxes can identify such MiTM attacks and protect endpoints.

> to perfectly impersonate the device.

Network security services have been using TLS profile parameters to
successfully identify malware and benign flows for several years. The data
features and ML models used by the security services is a public domain
information and also known to malware developers for a long time (for
example see https://arxiv.org/pdf/1607.01639.pdf).

> Given that TLS1.3 makes so many of the

Middle boxes from several security vendors acting as TLS proxies do keep up
with the updates to protocols (especially TLS) and strive be complaint TLS
middle boxes. You may want to look into the best practices for implementing
TLS proxies discussed in
https://tools.ietf.org/html/draft-wang-tls-proxy-best-practice-00.

> I don't think that section 4.1 needs to explain how BRSKI works.

Yes, the mechanism to bootstrap the IoT device with the middlebox's CA
certificate need not be discussed; will remove.

> patient data that could be spoofed like this might be considered to be

Yes, both security and privacy are required. Network security services
typically have a configuration option to act as a TLS proxy for endpoints.
It is up to the IT admin to determine whether the network security service
should terminate the TLS connection for a endpoint and destination address.
For example, IT administrator can configure firewall to bypass traffic
decryption
for a connection destined to a healthcare web service due to privacy
compliance requirements. Further, TLS proxies do protect the privacy of the
user and do not store PII data (See sections 4.9 and 4.10 in
https://tools.ietf.org/html/draft-wang-tls-proxy-best-practice-00#section-4.9
).

We will update the draft to clarify a middlebox can as a (D)TLS proxy for
the IoT devices managed by the IT team and the (D)TLS proxy must meet the
security and privacy requirements of the organization.

> I would certainly want to do this for firmware updates.

I don't get your comment. How will malware's command and control server
certificate be signed by the baked-in non-public trust anchor on the IoT
device ?

> me that much of this effort is a mis-guided relic of pre-MUD DPI IDS

No, we are using MUD for IoT devices in our product
https://securehomeplatform.mcafee.com/ but as you already know MUD is not
suitable for IoT devices with broad communication pattern. TLS profile
parameters can be used on such devices to permit intended TLS use and block
malicious TLS use.

>
> I suggest that section 4.2 reference
> draft-richardson-opsawg-mud-iot-dns-considerations-01.
>

> I didn't understand the purpose of the SPKI pin info mentioned in section

SPKI pin info can be configured on the IoT device to validate self-signed
server certificates or raw public keys (we  observed IoT devices
communicating with legitimate servers using self-signed certificates and
malware C&C servers also use self-signed certificates). SPKI pin info helps
to permit benign TLS flows using self-signed certificates and block malware
TLS flows using self-signed certificates.

> (Perhaps defining the profile(s) once and then re-using it)

Good point, will update.

Cheers,
-Tiru

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

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.

    > 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: Michael Richardson <[email-masked]>
Date: Tue, 21 Jan 2020 20:35:58 -0500

tirumal reddy <[email-masked]> wrote:
    > No, the proposed mechanism will help identify the presence of
    > unauthorized software or malware on an IoT device.

I understand that there is a lot of prior art and industry experience doing
this.  A lot of people are quite upset about how these things have
progressed, but it is not my purpose to tell people how they can or can't run
their network.  It's not my point to argue here.

I am actually in favour of end-to-end authentication and hop-by-hop
encryption, permitting controlled and clearly authorized auditing.
I even wrote draft on this topic in 1996.... (for IPsec)

    mcr> 2) it seems that manufacturers might be able to say, "HANDS OFF"
    mcr> to IDS systems. (perhaps avoiding use of more colourful language)

    > already have the capability of performing 
    > TLS handshake inspection and acting as a TLS proxy, they can leverage
    > the proposed mechanism.

It will be easier for vendors to avoid interposing themselves on
communications that would present legal problems if this extension can
clearly say hands-off.

    > Middle boxes from several security vendors acting as TLS proxies do
    > keep up with the updates to protocols

Well, it's never the good actors that cause the problem.
It's the bad ones :-)

    > a really bad idea. Devices that are willing to fall prey to such a

The problem here is that the EST mechanism as envisioned by BRSKI is not
intended to be a general trust anchor, but rather to validate items that are
within the same domain.

I just don't think that this is a good way to introduce alternate trust
roots.  My recommendation is that you go ahead with the MUD profile that
describes TLS profiles, without tying that to TLS proxy mechanisms.

    mcr> Additional, it is entirely reasonable (perhaps, given MITM attacks!) for an IoT
    mcr> device manufacturer to "call home" using a baked in, non-public, trust
    mcr> anchor. Such a situation would be indiguishable from malware calling C&C
    mcr> using a baked-in trust anchor.
    mcr> I would certainly want to do this for firmware updates.

    > certificate be signed by the baked-in 
    > non-public trust anchor on the IoT device ?

The malware will include it's own non-public trust-anchor.

    mcr> Given that MUD can clearly control where connections are made, it seems to
    mcr> me that much of this effort is a mis-guided relic of pre-MUD DPI IDS systems.

The point here is that MUD can keep the malware infected device from calling
the C&C server completely.  We don't have to do TLS profiling to detect that connection.

    > https://securehomeplatform.mcafee.com/ but as you already 
    > know MUD is not suitable for IoT devices with broad communication
    > pattern. TLS profile parameters can be used 
    > on such devices to permit intended TLS use and block malicious TLS
    > use.

I understand this use --- for broad communication patterns.

I think that my document draft-richardson-opsawg-mud-acceptable-urls might
help with rapidly updating TLS profile info as new firmware is updated.

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jan 2020 20:38:00 +0530

Hi Michael,

Please see inline

> encryption, permitting controlled and clearly authorized auditing.

Glad to see we are in the same page :)

> communications that would present legal problems if this extension can

I don't get the comment. The decision whether to deploy a TLS proxy for the
IoT devices/endpoints is up to the organization owning them. The TLS proxy
has to meet the organization security and privacy requirements. Further,
middle box administrator configure the firewall to bypass
traffic decryption for a connection destined to a specific service due to
privacy compliance requirements.

Malware identified last year is using DoH to hide the DNS messages from
passive monitoring (see (
https://www.bleepingcomputer.com/news/security/psixbot-modular-malware-gets-new-sextortion-google-doh-upgrades/
)
and such malware communication cannot be detected by DNS based filtering,
malware agents will not use the DoH/DoT server provided by local network,
TLS profile parameters can be used to detect malware communication with C&C
server for IoT devices with broad communication patterns.

As you may already know, Windows recently had a vulnerability in the
certificate validation function and would accept spoofed certificates
certificates (you can image the problems with IoT devices). Samsung fridge (
https://www.theregister.co.uk/2015/08/24/smart_fridge_security_fubar/)
accepted spoofed certificates because it failed to validate the server
certificate (imagine the problems with off-the IoT devices, see
https://tools.ietf.org/html/draft-arkko-farrell-arch-model-t-01#section-2.3.1.9
).

> Well, it's never the good actors that cause the problem.

I don't think organizations who care about security and privacy, and most
importantly their reputation and business will deploy such bad TLS proxies.

> describes TLS profiles, without tying that to TLS proxy mechanisms.

Got it, thanks; updated draft to say the mechanism to configure the IoT
device with the middlebox's CA certificate is out of scope.

> The malware will include it's own non-public trust-anchor.

If malware uses it's own non-public trust-anchor, it will be detected by
the TLS profile (acceptlist-ta-certs and SPKI-pin-sets) and the
malware flow will be blocked.

> the C&C server completely.  We don't have to do TLS profiling to detect

I don't get your response. MUD cannot be used to detect communication with
a C&C server for IoT devices with broad communication patterns. Further,
the malware agent may not do a DNS lookup (for example, I have seen malware
agents that obtain the C&C IP addresses as part of random text served from
established information source (e.g. websites such as blogs)) OR malware
using DoH to hide DNS messages OR malware using privacy enhancing
technologies like Tor (no DNS lookup is required).

> help with rapidly updating TLS profile info as new firmware is updated.

Yes, Thanks.

Cheers,
-Tiru

---

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

> privacy compliance requirements.

In Enterprises that own and control all device that might be true.
In residential situations where the ISP owns the home router, that's not true.

    > importantly their reputation and business will deploy such bad TLS proxies.

But, those bad ones meant that TLS 1.3 had to adapt to them, rather than the
other way around.

    >> intended to be a general trust anchor, but rather to validate items that

    mcr> I just don't think that this is a good way to introduce alternate
    mcr> trust roots.  My recommendation is that you go ahead with the MUD
    mcr> profile that describes TLS profiles, without tying that to TLS proxy mechanisms.

    > device with the middlebox's CA certificate is out of scope.

    mcr> The malware will include it's own non-public trust-anchor.

    > malware flow will be blocked.

I'm trying to say that the same process is a reasonable way for the device to
call home for firmware updates.   So I suggest that since we have MUD
ACLs, even for devices which might have relative broad connectivity, we
should be able to declare a TLS profile (or anchor profile) for specific
destinations.

---

From: tirumal reddy <[email-masked]>
Date: Fri, 24 Jan 2020 17:30:24 +0530

> In residential situations where the ISP owns the home router, that's not

Yes, TLS proxy approach will not work in home networks. In addition, I
don't think in near future home routers will be powerful enough to run a
TLS proxy (with the exception of VNF). Alternatively, the middle-box can
probe the server to learn the server certificate.

We will update the draft to clarify the scope of the deployments where
middle-box can act as a TLS proxy.

> But, those bad ones meant that TLS 1.3 had to adapt to them, rather than

The bad ones will continue to be non-compliant, see
https://tools.ietf.org/html/rfc8446#section-9.3

>     >> intended to be a general trust anchor, but rather to validate items
> that
>     >> are
>     >> within the same domain.
>

Good point, will update draft.

Cheers,
-Tiru