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

[Michael Richardson <[e-mail]>]

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

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

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

    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.

    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.

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

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