> On 21 Jan 2020, at 14:49, David R. Oran <[email protected]> wrote: > > On 21 Jan 2020, at 5:24, Eliot Lear wrote: > > Hi Mohit > > On 21 Jan 2020, at 11:07, Mohit Sethi M <[email protected]> wrote: > > Hi Eliot, > > I find your example rather disturbing. I am sure a dad does not want everyone > else on the Internet to see what his daughters toy is exfiltrating. You would > need encryption for that? > > Yes, you would! But Dad might want to be able to have an agent to decrypt. > > Sure, which is why key sharing is probably appropriate and having standards > for doing that safely are important. Do we have a good way to maintain PFS in > those scenarios? >
Certainly not with TLS 1.3, and that is by design. With TLS 1.2 it’s possible, but then we end up with divergent code bases, and I would like to avoid that. > Indeed Dad may want an agent that blocks certain > > I can see two related reasons why this might be important: > > To prevent “packet of death” scenarios where either bugs or malware can be > exploited by a single crafted packet making it through to a vulnerable device. > > To mitigate DoS attacks against devices that are not prepared to discard > traffic effectively, either due to processing or energy considerations. > > 1 is quite difficult to achieve without full middle-box functionality > Wellll…. It depends. Again, I’m reminded of Hitchhiker’s Guide to the Galaxy: “Space,” it says, “is big. Really big.” Same with IoT. If we’re talking about a digital twin strategy or some cloud-based service, the chances are ACLs are good enough, so long as you can identify the correct ACLs. But… if the threat here really is the device itself in its fully functional form without any malware, then you need a full scale ALG to defend against it. That’s something that we need to be thinking about. > 2 could be done with ACLs based on information in things like MUD profiles, > but I’d argue a better approach is something similar to STUN, but whose > purpose is for the device to install filtering or rate-limiting state in a > cooperating device “upstream of it”.. > It’s a matter of who you want making the claim. If it’s the device, then STUN or another half dozen protocols can do the job. If it’s the manufacturer who designed the thing, then MUD is the right tool.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
