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

[Michael Richardson <[e-mail]>]

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

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.

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

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

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

    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.

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

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.

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