Re: [DNSOP] Favor: Weigh in on draft-ietf-ipsecme-split-dns?

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:

> On Thu, 29 Nov 2018, Ted Lemon wrote:
>
> > On Thu, Nov 29, 2018 at 12:31 AM Paul Wouters <[e-mail]> 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."
> >
> >
>