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
