tirumal reddy <[email protected]> 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
