On Aug 1, 2017, at 10:48 AM, STARK, BARBARA H <bs7...@att.com> wrote: > The CABF is about "publicly trusted certificates". There is no need or > applicability of "publicly trusted certificates" in the context of a home > network. No certificate authority in the world is capable of certifying that > a device inside a specific home network actually belongs there. The only > entity capable of identifying devices that belong in the home network is the > home (network) owner. This isn't about public trust. It's about private trust.
This distinction is meaningless, unfortunately, because it's browsers that we need to trust the network, and we absolutely do not want to install a network-specific trust anchor in every end-user browser. Even if that were possible, it would be a gaping attack surface. > In reading Stephen's email about what he did wrt certificates, what stood out > to me were: > (1) The primary goal was to stop the annoying browser warnings. [note that > neither HNCP nor Babel would be expected to check against CAs stored in > browsers, so they would not be subjected to this annoyance; but the annoyance > is something to prevent when considering the broader "naming architecture"] (1) this isn't an issue for HNCP or babel. It's an issue for browsers. (2) the issue with browser warnings isn't that they are annoying. It's that if we train users to click through them when managing the homenet, we are also training them to click through them at other times. This creates an attack surface in the user that we'd rather not create. > (2) Stephen (the home network owner) was the assigner of trust. He was the > root certificate authority. This doesn't work because there is no grammar for ascribing different meanings to different trust anchors in browsers, as far as I know. Attempts have been made, but it's ultimately binary: the end user doesn't perceive the difference. Without such a grammar, we don't have a way to make Stephen the assigner of trust for his network without making him a potential assigner of trust for all networks for any device that considers him an assigner of trust. > 1. End users would like to know that device software / firmware has no > Trojans and is "good". This is not a good fit for X.509 certificates or PKI. > This would be something for some logo-based certification program (like a UL, > Good Housekeeping, IPv6 Ready, etc. stamp). I think this is outside the > (current) scope of homenet and there are other orgs working on this sort of > thing. In any case, it has nothing to do with encryption and X.509 > certificates. I think that people are talking about code signing elsewhere in the IETF; I would say that that is where this particular problem would need to be addressed. I think there's work here relating to TEEP, but also to just regular code signing. > 2. End users are the absolute (root) authority as to what does and doesn't > belong on the home network. No one else. Even in the case of "unmanaged" home > networks. Verisign and others are incapable of telling me whether or not a > device belongs on my home network. Sure. > 3. End users want it to be very easy to add devices/services to the home > network. Sure. > 4. End users want it to be very easy to remove devices/services. Sure. > 5. End users want to know when devices on the home network are misbehaving, > and they want to easily identify such devices. Yes. > 6. End users don't want annoying "untrusted" warnings for devices and > services inside the home network that they have decided to add to it. Yes, but s/annoying/attack-surface-generating/ > Does this seem like a reasonable list? Are there items y'all disagree with? > Others to add? I think this is a good start. What might become interesting are the implications of this list: what it would take to actually satisfy these requirements. :)
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
