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

[tirumal reddy <[e-mail]>]

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

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

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.


>
>     >> > 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 bad ones will continue to be non-compliant, see
https://tools.ietf.org/html/rfc8446#section-9.3


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

Good point, will update draft.

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