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?
> Indeed Dad may want an agent that blocks certain I can see two related reasons why this might be important: 1. 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. 2. 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, in which case I’d argue that rather than ACL-like blockage based on things like ports, you want a full application proxy that acts as an “agent” fronting the device. In this case the intermediary is trusted and already should have the necessary keys. #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”. My 2¢, FWIW… > >> >> I am totally with you on the need for knowing what's inside the device and >> how is the device behaving. RFC 8576 identifies this in Section 5.6 >> 'Verifying Device Behavior':https://tools.ietf.org/html/rfc8576#section-5.6 >> <https://tools.ietf.org/html/rfc8576#section-5.6> > > Well indeed. But I do think we should be considering what the first class > objects are in these cases. > > Eliot DaveO
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
