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

[tirumal reddy <[e-mail]>]

Hi Michael,

Please see inline

On Wed, 22 Jan 2020 at 07:05, Michael Richardson <[e-mail]>
wrote:

>
> tirumal reddy <[e-mail]> 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.
>

Glad to see we are in the same page :)


> 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)
>
>     > 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.
>
> 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.
>

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
).


>
>     > 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 :-)
>

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


>
>     > 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
>
> 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.
>

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


>
>     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.
>
>     > 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 ?
>
> 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.


>
>     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.


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).


>
>     > 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 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.
>

Yes, Thanks.

Cheers,
-Tiru


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