Separately, on the topic of provisioning, the right answer here is to just say that the whitelist is installed with the provisioning profile, and not recommend a UI flow. It's the recommendation for the UI flow that I'm objecting to. This is a bad security practice that is slowly falling into disfavor. I admit I'm ahead of the curve on this, but the writing is on the wall, and again, I'm not asking for ponies here. I agree that if you are going to use the whitelist method, you need to install it somehow. I do not agree that you need to advise implementors to do something which, while presently common, is actually a bad practice.
On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters <p...@nohats.ca> wrote: > On Thu, 29 Nov 2018, Ted Lemon wrote: > > > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters <p...@nohats.ca> wrote: > > How could the use case be more constrained without breaking > functionality? > > > > I discussed this in detail in several previous posts, e.g.: > > > https://mailarchive.ietf.org/arch/msg/dnsop/97xk8Zm1NGpyadZ8lsL3MhRtYGk > > https://mailarchive.ietf.org/arch/msg/dnsop/hkRowALa5yT4IoSmqCpdZg4e78I > > Well, you argued for changing things so much that it breaks > functionality :) And you would require the VPN client to have > some kind of DNSSEC resolving capability before the tunnel is > setup. And if those checks need to be done during tunnel setup > then there is also a significant delay that would affect on-demand > tunnels. > > I especially disagree with your text: > > I think that we should let the field tell us before figuring out > how to solve that problem. > > > I explained this in the previous posts. I would be happy (really!) to > help improve the text, but it would be a significant change, and I'm > getting the impression from > > Warren that he would like to not do that.. > > More specifically, the enterprise use case should not be further changed > to a more manual problem. In our previous discussions, both with the list > and the Security AD, we made it clear that this is as far as we can go > without destroying the enterprise use case. That is, let the provisioning > provide the list of names for override, give software a chance to warn, > and treat it otherwise as trusted enterprise provisioning. It is up to > the implementations on how or where they would support internal trust > anchors. For example a phone OS could limit this via "enterprise managed" > phone modes only and not allow "emailed profiles" to have these trust > points. > > >> Have you ever installed a Configuration Profile on iOS device? If your > profile contains a VPN profile which contains a PkCS12 it will warn (entity > installing this > >> can monitor all your traffic) and show you the root CA. > > > > Yes. That's a very bad UI flow. It means that I can just hand you a > configuration profile to install, and you can install it easily. And you > will install it—you're > > installing it because you want to get something, and when you're > presented with "ok" or "cancel," it's going to be very clear to you that > "ok" will get you whatever it > > is that you want, and "cancel" will not get you what you want. So even > offering the user this choice has created a gigantic attack surface.. I > think of UIs like this > > as "social engineering enablement UIs." > > Well, this is where rubber meets the road. There is nothing I can come > up with that will be rejected by the people who want to see dancing > hamsters or playful kittens. An enterprise can hand out phones that > are restricted with respect to provisioning and they can control it > as they see fit. If such an enterprise wants to support BYOD, they > can choose to forbid these trust anchors on those phones and/or > limit those VPN connections in other ways. > > If you let random internet companies install profiles with various > kinds of super powers, no RFC in the world will stop them. > > Paul > > > > > > > The idea of the text is that this can be similarly done and > warning you about the domains whitelisted. That would help if it suddenly > lists gmail.com or > > yahoo.com. I believe this adds value and is better than not > presenting the whitelist. Ignorant users will just click click click > regardless and knowledgeable > > users can go “wait a minute” > > > > > > I assume that knowledgable users will do the right thing if given the > right information; often these dialogs do not actually give the right > information. But it's the > > ignorant users I actually care about, because there are probably three > or four orders of magnitude more of them. As a knowledgable user, UIs > like this actually create > > a lot of stress for me, because they never actually tell me what they're > going to do, and yet I know that if they are doing something other than > what I hope they are > > doing, clicking "yes" will create a new attack surface on my device. > So I usually click "no," even though it's probably okay to click "yes." > If we want devices to be > > more secure, we have to come up with UI flows that get the user what > they need without forcing them to choose between "win and get hacked" and > "lose and don't get > > hacked." > > > > >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
