On Wed, 22 Jan 2020 at 22:55, Michael Richardson <[email protected]> wrote:
> > 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. > 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 [ > ] [email protected] http://www.sandelman.ca/ | ruby on > rails [ > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
