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

[Paul Wouters <[e-mail]>]

On Fri, 30 Nov 2018, Ted Lemon wrote:

> 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.

There is no "recommendation". There is a MAY clause:

    To determine this, an
    implementation MAY interactively ask the user when a VPN profile is
    installed or activated to confirm this.  Alternatively, it MAY
    provide a special override keyword in its provisioning configuration
    to ensure non-interactive agreement can be achieved only by the party
    provisioning the VPN client, who presumbly is a trusted entity by the
    end-user.

It seems our views differ here, which I would say is covered by the MAY
not being a SHOULD/MUST or RECOMMEND.

> 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 disagree and find your reasoning a little conflicting. Your proposal
is to always leave the user uninformed, ensuring that all users might
not be aware of anything. This gives individuals who would recognise
"do you agree to whitelist gmail.com" for VPN provider Cheap Access Inc
no more notification to stop installing the provisioning changes.

I explained big company's like Apple already do this when installing a
Root CA as part of a provisioning step, and it seems logical to do the
same for DNSSEC based trust anchors as we do for WebPKI based trust
anchors.

> I agree that if you are going to use the whitelist method, you need to install it somehow.

I am glad we agree there :)

> I do not agree that you need to advise implementors to do something which, while presently common,
> is actually a bad practice.

I hope my explanation above about not recommending it but not forbidding
it either is good enough for both of us.

Paul

> 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."
>       >
>       >
> 
> 
>