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

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Nov 2018 11:17:50 -0500

Hi there DNSOP,

I (and a number of IESG folken) would like some feedback / guidance on
draft-ietf-ipsecme-split-dns.

This document (which has gone through IESG eval, and on which I'm currently
holding a DISCUSS) attempts to solve the problem of accessing internal
domains when using a split-tunnel VPN.

Here is the abstract:

"This document defines two Configuration Payload Attribute Types
(INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key
Exchange Protocol Version 2 (IKEv2).  These payloads add support for
private (internal-only) DNS domains.  These domains are intended to
be resolved using non-public DNS servers that are only reachable
through the IPsec connection.  DNS resolution for other domains
remains unchanged.  These Configuration Payloads only apply to split
tunnel configurations."

Okey dokey, this sounds reasonable, and solves a problem which probably
shouldn't exist, but does.

The concerning scenario for me (and where I'd like the WG to provide
feedback if I'm being overly twitchy) is:
"The INTERNAL_DNSSEC_TA attribute type is used to convey a DNSSEC
trust anchor for such a domain.  This is required if the external
view uses DNSSEC that would prove the internal view does not exist or
would expect a different DNSSEC key on the different versions
(internal and external) of the enterprise domain."

Let's say I'm visiting Elbonia and really really want to watch "The Great
British Baking Show" on Netflix. Elbonia blocks all baking shows[0], and so
I figure I'll fire up my VPN, provided by "VPNs-R-Us - only $1.99 per
month, don't torrent without it!".
As you can guess from the name, VPNs-R-Us is sketchy, but, hey, they were
cheap! (They make up the profit by being malicious).

So, I fire up my IPSEC VPN client, and it pops up a box saying "VPNs-R-Us
wants to provide you with DNS servers for [.com, farfetch.com ] and DNSSEC
Trust Anchors for the same. Continue [Y/N]?". Being a users, desperate  to
watch Paul Hollywood disapprove of someone's puff pastry, I click "Yes"
(admit it, you would too!).
I then browse to www.paypal.com to see if I can buy a shirt just like Noel
Fielding's.

My DNS request goes to VPNs-R-Us, who (because they have provided me with a
DNSSEC TA for .com) answers with 6.6.6.6 and a "validly" signed DNSSEC
answer. They also "helpfully" provide me with a TLSA record, and when I
connect provide me with a certificate with the DNSSEEC chain extension.

The document attempt to mitigate issues like this with: "Other generic or
public domains, such as top-level domains (TLDs), similarly MUST be ignored
if these appear in a whitelist unless the entity actually is the operator
of the TLD. 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.", discussions in the Security
Considerations, etc.

I believe that the document is trying to solve a real world problem, but
I'm concerned by the ability to push DNSSEC TAs, and rely on user's ability
to make an informed decision (keeping in mind their behavior when presented
with big red "Are you sure you want to accept this random TLS
certificate?!" browser boxes).

So, would y'all mind weighing in to help me decide what I do with my
DISCUSS? Do the benefits outweigh the risks? Allowing this potentially
allows for DNSSEC signing of things like internal TLDs / internal
namespaces, increasing DNSSEC deployment. Am I being overly cautious here?
Should users know better than to blindly click OK on things they don't
understand?

I'd really like your advice, preferably before Friday.

The document: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/
The balloting:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/

The thread on my DISCUSS:
https://mailarchive.ietf.org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc

W
[0]: Lest their citizens start wondering why they don't also have cake.

--
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Joe Abley <[email-masked]>
Date: Mon, 26 Nov 2018 11:31:01 -0500

Hi Warren,

It seems to me that the intended use-case is access to corporate-like network environments where intranet.corporate-like. <http://intranet.corporate-like.com/>com might exist on the inside but not on the outside. Whether access is through a VPN or WPA2-protected WiFi or an RJ45 jack on the wall in a locked room seems orthogonal to the problem space, so I'm not sure why the VPN example needs additional facilities that the others don't have.

If you sign both your internal-facing and external-facing view of your zone with the same KSK, surely you don't need an additional TA to make it work in any of those example cases? The DS RRSet in your parent is all anybody needs.

I share your concern that there's no obvious way to limit the scope of the TA when the only administrator in the picture is a baking-obsessed, jet-lagged, non-technical user in a hotel room at 4am.

In general, I think dissemination of a new TA to a validator is a serious business and shouldn't be done quietly if there's a chance that a non-technical end-user is driving.

Joe

> On 26 Nov 2018, at 11:17, Warren Kumari <[email-masked]> wrote:
> 
> Hi there DNSOP,
> 
> I (and a number of IESG folken) would like some feedback / guidance on draft-ietf-ipsecme-split-dns.
> 
> This document (which has gone through IESG eval, and on which I'm currently holding a DISCUSS) attempts to solve the problem of accessing internal domains when using a split-tunnel VPN.
> 
> Here is the abstract:
> 
> Okey dokey, this sounds reasonable, and solves a problem which probably shouldn't exist, but does.
> 
> The concerning scenario for me (and where I'd like the WG to provide feedback if I'm being overly twitchy) is:
> Let's say I'm visiting Elbonia and really really want to watch "The Great British Baking Show" on Netflix. Elbonia blocks all baking shows[0], and so I figure I'll fire up my VPN, provided by "VPNs-R-Us - only $1.99 per month, don't torrent without it!".  
> As you can guess from the name, VPNs-R-Us is sketchy, but, hey, they were cheap! (They make up the profit by being malicious).
> 
> So, I fire up my IPSEC VPN client, and it pops up a box saying "VPNs-R-Us wants to provide you with DNS servers for [.com, farfetch.com <http://farfetch.com/> ] and DNSSEC Trust Anchors for the same. Continue [Y/N]?". Being a users, desperate  to watch Paul Hollywood disapprove of someone's puff pastry, I click "Yes" (admit it, you would too!)..
> I then browse to www.paypal.com <http://www.paypal.com/> to see if I can buy a shirt just like Noel Fielding's.
> 
> My DNS request goes to VPNs-R-Us, who (because they have provided me with a DNSSEC TA for .com) answers with 6.6.6.6 and a "validly" signed DNSSEC answer. They also "helpfully" provide me with a TLSA record, and when I connect provide me with a certificate with the DNSSEEC chain extension..
> 
> The document attempt to mitigate issues like this with: "Other generic or public domains, such as top-level domains (TLDs), similarly MUST be ignored if these appear in a whitelist unless the entity actually is the operator of the TLD. 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.", discussions in the Security Considerations, etc. 
> 
> I believe that the document is trying to solve a real world problem, but I'm concerned by the ability to push DNSSEC TAs, and rely on user's ability to make an informed decision (keeping in mind their behavior when presented with big red "Are you sure you want to accept this random TLS certificate?!" browser boxes).
> 
> So, would y'all mind weighing in to help me decide what I do with my DISCUSS? Do the benefits outweigh the risks? Allowing this potentially allows for DNSSEC signing of things like internal TLDs / internal namespaces, increasing DNSSEC deployment. Am I being overly cautious here? Should users know better than to blindly click OK on things they don't understand?
> 
> The document: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/>
> The balloting: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/ <https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/ballot/>
> 
> The thread on my DISCUSS: https://mailarchive.ietf..org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc <https://mailarchive.ietf.org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc>
> 
> 
> W
> I don't think the execution is relevant when it was obviously a bad idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
>    ---maf
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2018 11:42:55 -0500

I think it's pretty clearly the case that the VPN provider should not be
automatically assumed to be trusted.   Most VPNs that people use nowadays
aren't trustworthy in that sense.   Also, I think that we should draw a
hard line in the sand that it's never okay to override DNS trust.   I can't
actually think of a use case where it makes sense to do this.   It's fine
to add trust when it can be validated that without adding that trust, no
trust would exist.   But it's never okay to override a valid trust
delegation.

IOW, the way to solve this problem is to have a valid chain of trust from
the root, not all of which can be seen by the end user without going
through the VPN.   Then if there's a censorship issue, you just fetch the
whole chain of trust over the VPN, and it validates.   If you want to
provide a trust anchor that is different than what's present in the public
delegation, the way to do this is to have an unsigned delegation, so that
the conflicting trust anchor increases trust, rather than changing it.

On Mon, Nov 26, 2018 at 11:18 AM Warren Kumari <[email-masked]> wrote:

> This document (which has gone through IESG eval, and on which I'm
> currently holding a DISCUSS) attempts to solve the problem of accessing
> internal domains when using a split-tunnel VPN.
>
> Here is the abstract:
>
> wants to provide you with DNS servers for [.com, farfetch.com ] and
> DNSSEC Trust Anchors for the same. Continue [Y/N]?". Being a users,
> desperate  to watch Paul Hollywood disapprove of someone's puff pastry, I
> click "Yes" (admit it, you would too!)..
> I then browse to www.paypal.com to see if I can buy a shirt just like
> Noel Fielding's.
>
> My DNS request goes to VPNs-R-Us, who (because they have provided me with
> a DNSSEC TA for .com) answers with 6.6.6.6 and a "validly" signed DNSSEC
> connect provide me with a certificate with the DNSSEEC chain extension..
>
> The document:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-split-dns/
> The balloting:
> https://mailarchive.ietf..org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc
> <https://mailarchive.ietf.org/arch/msg/ipsec/5xvXIidXt3DgxO_V0V8Haosb1Uc>
>
>
> W

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 Nov 2018 17:04:56 +0000

Joe Abley <[email-masked]> wrote:
>
> It seems to me that the intended use-case is access to corporate-like
> network environments where intranet.corporate-like.com might exist on
> the inside but not on the outside.

More likely cases like corporate-like.local or corporate-like.int or
like.corp etc. usw. :-(

Private DNSSEC trust anchors should be distributed in the same way that
you would distribute corporate X.509 trust anchors.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
an equitable and peaceful international order

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2018 12:31:30 -0500

If there's no delegation from the root, and it can be validated that there
is no delegation from the root, then the attack surface that this draft
provides is that your corporate private DNSSEC on foo.corp can be
overridden by the VPN.   So as you say, Tony, even in this case, the right
way to do this is not to allow the VPN to provide the trust anchor in-band.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Nov 2018 18:28:36 +0000

On Nov 26, 2018, at 8:17 AM, Warren Kumari <[email-masked]> wrote:
> As you can guess from the name, VPNs-R-Us is sketchy

If you trust a VPN operator, you trust the VPN operator. What the rest of your message is asking is "can I partially trust the VPN operator to do X but not Y, and have all that be explicit?".

25+ years of IETF security experience would say either "no" or "yes, but in such a convoluted way that no one will actually understand it and now you've just slathered on complicated code that makes things worse".

Once you are inside a network (the N in VPN), it's "my network, my policy" all over again.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Nov 2018 13:36:57 -0500

> Once you are inside a network (the N in VPN), it's "my network, my policy"

Can you unpack what you mean by this?   I assume you don't mean that we
should provide a mechanism whereby network operators can automatically
override DNSSEC trust anchors!

---

From: Joe Abley <[email-masked]>
Date: Mon, 26 Nov 2018 13:37:56 -0500

> If you trust a VPN operator, you trust the VPN operator. What the rest of your message is asking is "can I partially trust the VPN operator to do X but not Y, and have all that be explicit?".

I think you can trust a VPN provider to make iPlayer work when you're not in the UK, or to get a better menu of television on Netflix, or to obscure the fact that you like to visit webpages that might get you a letter from the MPAA, but it could well be a stretch to say that you trust them not to subvert the DNS when you visit Paypal. The average end-user doesn't know what DNS is, never mind DNSSEC.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 26 Nov 2018 18:43:04 +0000

On Nov 26, 2018, at 10:36 AM, Ted Lemon <[email-masked]> wrote:
> Can you unpack what you mean by this?   I assume you don't mean that we should provide a mechanism whereby network operators can automatically override DNSSEC trust anchors! 

For names that are only available within a trusted network, yes I really mean that. 

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 26 Nov 2018 14:03:54 -0500

In article <[email-masked]> you write:
>> Can you unpack what you mean by this?   I assume you don't mean that we should provide a mechanism whereby
>network operators can automatically override DNSSEC trust anchors! 
>

I agree with the sentiment, but when I'm writing my DNS validator, how
do I tell the names that are only available within the network from
the outside ones that the network operator is spoofing?

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Tue, 27 Nov 2018 07:59:04 +0700

This discussion would be better if people took warren’s example and then read the draft before commenting.

I will watch the discussion before responding further.

Thanks

Paul

Sent from mobile device

> On Nov 27, 2018, at 01:43, Paul Hoffman <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Nov 2018 00:28:35 -0500

> This discussion would be better if people took warren’s example and then read the draft before commenting.

I don't think that the answer changes much as a result of this, but it does change a little.  You've obviously put a lot of thought into how to put this particular square peg into a round hole.   It might be worth backing off a bit and looking at the use cases that I think you care about.   Here are six, roughly in order of how bad an idea they are, worst idea last:

Split DNS, no DNSSEC
Split DNS, DNSSEC, no trust anchor required because validation works on both sides of the split
Split DNS, DNSSEC, trust anchor required because the hidden zone provably doesn't exist
Split DNS, DNSSEC, trust anchor required because the hidden zone is under or at an unsigned delegation
Split DNS, DNSSEC, trust anchor required because the hidden zone has a secure delegation that won't validate
I want to attack you, and you want to let me

I am going to claim that case [1] is the use case that you really care about.   If you could just address case [1], you'd be nearly done.   Case [2] is a use case you care about if you are a DNSSEC fan.   Let me know if you need me to explain how to do it, but I assume you already know how.   Neither case [1] nor case [2] require the client to get trust anchors from the VPN provider.

A third vaguely plausible use case is that the service provider has a hidden domain that isn't correctly delegated, like .corp.   I think you can make an argument that this is a valid use case, and it does require that a trust anchor be installed.

The mitigation strategy for this would be to check to see that the existence of the zone is securely denied.   If so, and this is the case for example for .corp, then we can use the trust anchor without worrying that some legitimate public zone will be shadowed.   However, we still have the problem that two different versions of .corp could be configured at once.   Maybe not the scariest problem in the world, but okay, let's say this is a valid use case, and you can specify precisely how to allow it.   Probably check every time it's used to make sure its existence is still denied.   I think this use case makes sense for fake TLDs, and in no other case, so validating it is easy.

In cases four and five, you care enough to set up DNSSEC, but either can't be arsed to do it right, or don't have control over the delegation point and so can't do it right.   In the former case, I would argue that we should just say too bad.   In the latter case, we have just protected the end user from being attacked by saying too bad.

So I would argue that in both cases four and five, it should be impossible to install a trust anchor.   This is easy to do: when you are online, check to see if there's a secure path to an unsigned delegation above the zone.   If there is, then you can't use any trust anchor presented for that zone.   If you can't check, then you can't use the trust anchor either.

Secondly, check to see if there is a secure delegation.   If there is, you can't use the trust anchor.   If you can't check, you can't use the trust anchor.

I'm glossing over the fact that there are two steps to the process: installing the whitelist, and installing the trust anchor. I think it would be fine to do the checks when installing the whitelist, and then validate them every so often, maybe at least once a day.   There may be use cases where this prevents goodness from happening, but I think that we should let the field tell us before figuring out how to solve that problem.

One thing that the document says that absolutely must be taken out: there should be no way for a VPN to do something that presents me with a security dialog where I can decide whether not to allow it to whitelist a trust anchor. That's not a valid use case.   This is case six.

I think that the use case you want to address here is that an enterprise provisioning system needs to install a whitelist. This is not a user action.   The user should never be asked to do this, and should not even be able to do this unless they are smart enough to know that they need to do it and know how to do it without any prompting.   So the document should be quite explicit about that, and not recommend a UI flow that enables a social engineering attack.

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 Nov 2018 15:02:28 +0000

Ted Lemon <[email-masked]> wrote:

Snipped and edited to add numbering for reference...

> 4. Split DNS, DNSSEC, trust anchor required because the hidden zone is
> under or at an unsigned delegation
>
> 5. Split DNS, DNSSEC, trust anchor required because the hidden zone has
> a secure delegation that won't validate

[ snip lots of stuff I agree with ]

> In cases four and five, you care enough to set up DNSSEC, but either
> can't be arsed to do it right, or don't have control over the delegation
> point and so can't do it right.  In the former case, I would argue that
> we should just say too bad.  In the latter case, we have just protected
> the end user from being attacked by saying too bad.

Case 4 is pretty common for RFC 1918 reverse DNS :-)

Really, I don't think this is (just) a VPN issue: the question of how to
install DNSSEC trust anchors for private zones has not been solved for the
general case, so a VPN-only patch seems premature and unhelpfully specific
to me.

Tony.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Nov 2018 10:12:15 -0500

An explicit exception could be made for "locally served zones," which would
include RFC1918 zones.   We've thought a lot about this problem in homenet;
the conclusion we ultimately drew is that it's way too hard to try to come
up with a ToFu solution that adds value, and anything that's not automatic
is useless.   So we concluded that if you want DNSSEC, the right way to do
it is to have a delegation from the root.   If you don't have the
wherewithal to do that, you don't get DNSSEC on the homenet.

We also considered the  case of DNSSEC for reverse mapping zones.   I don't
know if I can safely say "we" here because I just presented my conclusion
and nobody argued with it.   But my conclusion was that I couldn't think of
a threat model that justified the complexity of signing a locally-served
reverse mapping zone.   The reverse mapping zone is of very limited
utility.   People occasionally use it for authentication, but I think
there's a pretty clear lack of consensus in the IETF that this is a good
idea, since it gets shouted down every time anyone mentions it.   The other
use is for annotating logs.   That's just not something that's useful
enough that attacking it makes sense even if the attack is easy.   Any
complexity that is added to make the attack harder than it already is is
simply adding risk, not removing it.

Because of the experience with homenet, I actually sort of disagree with
you about needing a general solution for this.   I think that the general
solution for this is not to do it.   If there are some specific corner
cases where doing it makes sense, then yes, having a document that talks
about the problem and how to mitigate the risks makes sense, but the
mitigation strategy is most likely always going to be solution-specific
anyway, as it is here.

---

From: Joe Abley <[email-masked]>
Date: Tue, 27 Nov 2018 10:28:04 -0500

> general case, so a VPN-only patch seems premature and unhelpfully specific

That is a more concise and straightforward rendering of the main point I was blathering about the other day.

To your point, Paul, I did see the text in the applicability and security considerations sections about ignoring the INTERNAL_DNSSEC_TA payloads in the case of non-split-tunnel situations. I understand the restriction to use in split tunnel scenarios, and the requirement to implement a whitelist, but I don't think either of those are particularly strong (and the consequences of ignoring or subverting them are more serious than I think the document gives credit for).

For the split tunnel restriction, my pedantic objection is that all VPNs whose payload and scaffolding uses a single protocol (e.g. an IPv4 tunnel endpoint to build a tunnel through which to send IPv4) is a split tunnel, since the tunnel endpoint needs necessarily not to be encapsulated by the VPN client. Local networks are also frequently excluded in non-split configurations, too. Where is the strict definition of "split tunnel"? This is a real question; you know more about tunnel semantics than I do.

My arguably more reasonable observation is that any non-enterprise, Netflix-gaming VPN service that wanted to be a bad actor could simply provide a split tunnel service (according to the definition I was looking for) described as something different, but covering enough of the IPv4 address space that the end-user had no real way of noticing, at which point the INTERNAL_DNSSEC_TA payload could presumably be accepted by the client.

 The whitelist provisions in section 7 seem too weak to me to prevent this. It seems highly likely that someone is going to copy and paste a configuration that is overly broad; in addition, there's no text to confirm that the whitelist ought to be per-VPN-service and not global configuration for the client. There's a risk that a whitelist that makes sense for one VPN could be exploited by a different one that ought not to be able to say anything about it.

In a strictly enterprise scenario it's not uncommon for the client configuration to be handled by the IT department as part of normal IT asset management. If the IT department is configuring the VPN client, is it really a stretch to imagine that they couldn't install a local validator and trust anchors at the same time? That would solve the .CORP and RFC1918-reverse cases for those end-users without having to worry about nefarious use of these proposed new payloads for end-users whose clients essentially have no informed administrator. If you expect administrators to maintain an accurate whitelist, surely they could just configure TAs and forward zones themselves. If there's no centralised mechanism to update that kind of configuration in a friction-free way to accommodate TA rolls then presumably the devices concerned should all be considered compromised and banned from connecting to the network anyway.

One more thought; in a possible future where it's applications like browsers that do validation and not an OS-provided stub resolver library, this proposal leaves a gap between the VPN client (which might receive new trust anchor information) and those applications (which need signalling to know that such new trust anchor information exists). That seems worth mentioning, even if it's out of scope to provide a solution.

As is probably obvious I don't particularly like this proposal, but I also acknowledge that I'm perhaps not the target audience and I'm missing context that would make it seem more useful. If it goes ahead, maybe some of the observations here could help.

Joe

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 Nov 2018 15:38:19 +0000

Ted Lemon <[email-masked]> wrote:
> solution for this is not to do it.

:-)

I was thinking more of "generally within the corporate context" - homenet
is (as you say) much more of a challenge. Within the corporate context I
think the general solution is to make this part of the managed machine
configuration (along with X.509 trust anchors, etc.), i.e. don't specify
the "internal" configuration details in-band, but just give the client
some kind of name for a collection of configuration settings it should
already have.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Southeast Biscay: Southerly or southwesterly 4 or 5, occasionally 6 in north.
Moderate or rough becoming rough or very rough. Mainly fair. Good.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Nov 2018 12:29:38 -0500

Yes, absolutely, although I think there are use cases that can be addressed
without special configuration on the laptop, so the document should
definitely explain how to set that up, or point to a document that does.

I'm assuming that the reason for including the TA option in the IKE
exchange is that it avoids having to keep something on the host up to date
if the trust anchor changes (maybe this was explicitly stated in the
document, but I didn't see it).   From that perspective, this makes sense
in the one use case that I think is valid for installing a trust anchor.
That case is when the VPN operator is using a bogus internal domain for
which they don't control the delegation.   In this use case, it makes sense
to have a whitelist for that bogus domain.   But the whitelist should be
validated by making sure that the bogus domain is the right sort of bogus
domain: a top-level domain for which there is a secure denial of existence
that is checked before the whitelist entry is installed, and that is
checked periodically after the whitelist has been installed.

Of course, arguably the owner of the device should be able to override even
this restriction, but I think that should be the default behavior, and
overriding the restriction should require the sort of managed machine
configuration you're talking about: it should be Really Hard and involve a
special arrangement, not something the end user can do by following the
instructions provided by the person who is doing a social engineering
attack on them.

But my suspicion is that it's not actually necessary to provide for this
use case: the people who are doing this are not likely to care about DNSSEC
on the VPN.   We could as easily address this use case by simply allowing a
whitelist for secure denial of existence on TLDs, and this would address
the problem of non-DNSSEC lookups, over the VPN, on .corp, for example.
 The whitelist entry would simply say "look, I know you see a secure denial
of existence here, but it's okay to do non-DNSSEC lookups in subdomains of
this particular zone, and these should not be rejected on the basis of the
denial of existence."   Once again, this really only makes sense for TLDs,
as far as I know, since for example if the delegation is for example.com,
presumably the VPN operator owns example.com and can set up a chain of
trust there.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 28 Nov 2018 15:12:41 +0200

> More likely cases like corporate-like.local or corporate-like.int or

Yes, this is the more common practice to use. I.e., several companies
quite often have (multiple) internal domains they use. Because those
are internal domains they cannot get real certificates for them.
Because they cannot use real certificates they use self signed
certificates, thus users have to click on "trust this web site having
invalid certificate yes/no". The idea is that with TLSA we could get
some kind of security for those internal sites.

More competent companies might also run their own CA and use that to
sign internal web sites, but unfortunately those more competent
companies usually then also have heavy IT processes that requires all
kind of complicated stuff to get things be signed by corporate CA, and
then developers setting up intranet / chat system / testing setup etc
revert to self signed certificates, because it is easy. On the other
hand getting DNS names added to the internal DNS is usually something
that happens often, and is not too hard to do, getting TLSA record
along with the name should also be quite easy.

Now when browsers start to make it harder and harder to allow access
to self signed certificates, users are seeing more and more problems
with that.

> Private DNSSEC trust anchors should be distributed in the same way
> that you would distribute corporate X.509 trust anchors.

This is exactly what is proposed by the draft, execpt that it is split
in two parts, i.e., the names for which TAs can be given are
distributed in same way as X.509 trust anchors, the actual contents
for the TA for that whitelisted name is distributed inside IKE.

The draft requires the whitelist to pre-configured before starting up
the VPN connection. It also do require implementations to ignore all
those settings unless user have explictly configured split-tunnel on
for that connection.

I.e., in the example the VPNs-R-Us would not be able to set those
configuration settings, nor would it be able to provide dialog asking
that.

VPN-R-Us would require provide instructions how to configure your VPN
client to do that, i.e., it would need to ask users to do following:

  - In your IPsec VPN configuration dialog click "Add" to add new VPN. 
  - Type in VPNs-R-Us for name, and IP of f00::BA5 as IP-address.
  - Click advanced
  - In Advanced settings to go the enterprise VPN tab
  - In there click the Enable Split-tunnel setup check box.
  - Answer YES to question verifying that you really want to configure
    this manually, and do not want to use the managment profile
    provided by the enterprise (normally enterprise VPN setups are
    managed automatically by profiles provided by the company, normal
    users usually do not even have option to change anything).
  - After that click "Add items to DNSSEC whitelist".
  - Type in "farfetch.com", and click OK.
  - (vpn client would probably forbid him adding .com to list as or if
    it is added it would be ignored), so VPN-R-Us is smart and asks
    following:
  - Type in "paypal.com" and click OK.
  - Click OK to few times and get the VPN configuration setup.
  - Then fire up the VPN client.

More likely VPN-R-Us would say if you do not want to do that, just
download this easy binary exe that will do all that configuration for
you (and some others they do not mention).

I.e., that whitelist needs to be modified out of band. Usually it is
done by the management system taking care of the enterprise profiles,
i.e., the same program that installs X.509 roots for the company CA,
and mandates that virus checkers are up to date before allowing
connection to the corporate network, and which also configures the VPN
connection too.

If you are running that kind of programs you have already given all
control to whoever provided you that program (VPN-R-Us, or the
enterprise).

In enterprise case, you usually do not have option not to, as those
softwares come pre-installed and you cannot uninstall or not to use
them. On the other hand do not use your work laptop to go to paypal,
if you do not trust your company...

And yes, the enterprise (or VPN-R-Us) management.exe could also
install those TAs directly for the global system use without any
problems. This would not be problem for the VPN-R-Us (they would be
happy to have fake TA in your system even when you are not using their
VPN), but enterprise might not want to have its TA there when you are
not connected to its network, just to limit the exposure, and they
might want to update the TA contens, even when the whitelisted domain
name stays same.

I.e., if the TAs cannot be transmitted and agreed to be taken in use
(after comparing them to whitelist) inside the IKE, then enterprises
will most likely just install them by the management system for
general use (or not use DNSSEC). I think that would weaken security
more than what is proposed in this draft.
-- 
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Nov 2018 16:53:45 -0500

So, thank you everyone for commenting / the feedback...

I've been mulling this over, and, while I really don't like it, I think
that the:
"IKE clients willing to accept INTERNAL_DNSSEC_TA attributes MUST use
a whitelist of one or more domains that can be updated out of band.
IKE clients with an empty whitelist MUST NOT use any
INTERNAL_DNSSEC_TA attributes received over IKE.  Such clients MAY
interpret receiving an INTERNAL_DNSSEC_TA attribute for a non-
whitelisted domain as an indication that their local configuration
may need to be updated out of band."

helps mitigate this -- as Tero says above, the user would have to jump
through many stupid hoops in order to make themselves vulnerable.
If think that if the text around "that can be updated out of band" were
strengthened (the current wording sounds like being updated out of band is
one option, but e.g being updated in-band and "approved" by the user is
another), and it were made a bit clearer how the whitelist might be managed
I'd be (grudgingly) willing to remove my DISCUSS.

Again, I don't love this, but I think that the mitigations can be made to
work, and it *does* solve a real world problem.

Can anyone *not* live with this?
W

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Nov 2018 07:47:15 +0700

On Nov 29, 2018, at 04:53, Warren Kumari <[email-masked]> wrote:
> 
> 
> helps mitigate this -- as Tero says above, the user would have to jump through many stupid hoops in order to make themselves vulnerable.

That’s what we came up with when we talked to ekr.

> If think that if the text around "that can be updated out of band" were strengthened (the current wording sounds like being updated out of band is one option, but e.g being updated in-band and "approved" by the user is another), and it were made a bit clearer how the whitelist might be managed I'd be (grudgingly) willing to remove my DISCUSS.

I have no problem making that text stronger / clearer.

> Again, I don't love this, but I think that the mitigations can be made to work, and it *does* solve a real world problem.

Yes, if we want enterprises to deploy DNSSEC, we need this. The internal/external views are almost always administrated by a different party, so the likelihood of sharing private key is extremely unlikely (plus we would be telling them how to run their infrastructure). 

> Can anyone *not* live with this?

I’m fine with the phrasing changes you are requesting.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Wed, 28 Nov 2018 19:49:06 -0500

I think the bottom line is that how risky this is really depends on the
implementation.   I can live with what's in the document on the basis that
I think the major OS vendors aren't stupid, and I hope this isn't going to
get stuffed into random cheap router firmware, but I'd definitely be
happier if the use case were more constrained and the implementation advice
were clearer.

One thing that I really don't like is the text that talks about users being
presented with confirmation messages.   That is an extremely bad message to
put into this document.   The user should never ever ever see an offer to
install one of these whitelists.   That's just the wrong UI flow.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Nov 2018 12:20:38 +1100

> On 29 Nov 2018, at 11:47 am, Paul Wouters <[email-masked]> wrote:
> 

You can also just publish DS records for both DNSKEY RRsets with the caveat that
both RRsets have to have all algorithms as is published in the combined DS RRset.

>> This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants..
>>    ---maf

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Nov 2018 13:30:52 +0800

> On Nov 29, 2018, at 08:49, Ted Lemon <[email-masked]> wrote:

> but I'd definitely be happier if the use case were more constrained

How could the use case be more constrained without breaking functionality?

> and the implementation advice were clearer.

What is unclear ? Do you have suggested improvement text?

> One thing that I really don't like is the text that talks about users being presented with confirmation messages.   That is an extremely bad message to put into this document.   The user should never ever ever see an offer to install one of these whitelists.   That's just the wrong UI flow.

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.

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”

Paul

>> I've been mulling this over, and, while I really don't like it, I think that the:

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Nov 2018 13:35:12 +0800

> On Nov 29, 2018, at 09:20, Mark Andrews <[email-masked]> wrote:
> 

True. But than you are publishing non-public internal network details on the public internet. And you still have to get different DNS groups to work together to update these in time. We thought it better to just whitelist the domains in the provisioning system and have the VPN gateway (automatically or manually) pull/update the proper DS records.

Paul

---

From: Petr Špaček <[email-masked]>
Date: Thu, 29 Nov 2018 09:10:54 +0100

On 29. 11. 18 1:47, Paul Wouters wrote:
> On Nov 29, 2018, at 04:53, Warren Kumari <[email-masked]
> <mailto:[email-masked]>> wrote:
>> If think that if the text around "that can be updated out of band"
>> were strengthened (the current wording sounds like being updated out
>> of band is one option, but e.g being updated in-band and "approved" by
>> the user is another), and it were made a bit clearer how the whitelist
>> might be managed I'd be (grudgingly) willing to remove my DISCUSS.
> 
>> Again, I don't love this, but I think that the mitigations can be made
>> to work, and it *does* solve a real world problem.
> 
> Yes, if we want enterprises to deploy DNSSEC, we need this. The
> internal/external views are almost always administrated by a different
> party, so the likelihood of sharing private key is extremely unlikely
> (plus we would be telling them how to run their infrastructure). 
> 

I'm wondering if we could add NXDOMAIN mandatory check and accept
INTERNAL_DNSSEC_TA only if "external DNS server" resolves given name to
NXDOMAIN.

It seems to me that it would eliminate most problematic cases like com.
hijack etc.

Only problem I can see are cases where "external view" actually serves
non-NXDOMAIN answers - I have no idea how common is that.

What do you think?

Petr Špaček  @  CZ.NIC

>> On Wed, Nov 28, 2018 at 8:12 AM Tero Kivinen <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Tony Finch writes:
>>     > Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
>>     > >
>>     > > network environments where intranet.corporate-like.com
>>     <http://intranet.corporate-like.com> might exist on
>>     > More likely cases like corporate-like.local or
>>     corporate-like.int <http://corporate-like.int> or
>>     > like.corp etc. usw. :-(
>>
>>       - Type in "farfetch.com <http://farfetch.com>", and click OK.
>>       - Type in "paypal.com <http://paypal.com>" and click OK.
>>     [email-masked] <mailto:[email-masked]>
>>
>>
>>
>> -- 
>> regret at having chosen those particular rabid weasels and that pair
>> of pants..
>>    ---maf

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Nov 2018 06:54:54 -0500

> 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

> What is unclear ? Do you have suggested improvement text?

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.

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

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

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 10:37:24 -0500 (EST)

> INTERNAL_DNSSEC_TA only if "external DNS server" resolves given name to

You cannot do that. Imagine .company being run locally and publicly.
They might still be different zones.

While it would be ideal for companies to put all their non-public stuff
in one internal zone (eg corp.example.com), we cannot and should not
require them to do so. Although we surely recommend them to do so.

> It seems to me that it would eliminate most problematic cases like com.

And introduce lots of new ones :)

> non-NXDOMAIN answers - I have no idea how common is that.

And I don't know how we would find out how common that is.

> What do you think?

I think in an ideal world, yes. but on this internet, no :)

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 10:53:29 -0500 (EST)

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

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2018 11:25:11 -0500

Paul, I think it is a bit much to accuse me of wanting a pony here.

Suppose you have a company that has a subdomain that's internal (this is
the case where they control the delegation).   The way you make this work
is that you publish a signed delegation to the internal zone.   When you
look things up in that zone outside the firewall, you get NXDOMAIN for
everything but the SOA on the zone, which returns an old serial number.
 Inside the firewall, they get answers, which are signed, and which
validate.   There's no need for a special trust anchor here.

So that works if the zone being queried is just nonexistent outside the
firewall.   If the zone looks different outside the firewall than inside
the firewall, it's a bit more complicated, but essentially similar.   There
are two ways to approach this.   One is to assume that the validator never
checks the SOA on the zone.   This is almost certainly the case for nearly
any use case.   In that case, you just run the internal and external name
servers with the same ZSK, and have a delegation above it.   You don't
worry about zone serial numbers, because they don't affect validation.
 When you're inside the VPN, you get answers for the internal zone; when
you're outside the vpn, you get answers for the outside.   Both validate,
because the DS record(s) are referring to the same ZSK(s).

If you really care about SOAs being accurate, then you need to update the
zones in lockstep: the external zone will always have a different serial
number than the internal zone, and they will always differ by one, with the
internal zone being the larger number.   Whenever you make a change to
either zone, you increment the serial numbers on both zones.   Answers from
the internal zone will always have the higher serial number, and therefore
be preferred.

So in this case, there is no need for a special trust anchor, and using one
makes you substantially less secure, and hence is not something we should
be advising.

On Fri, Nov 30, 2018 at 10:53 AM Paul Wouters <[email-masked]> wrote:

> getting the impression from
> installing this
> 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
> >       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
> > 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."
> >
> >
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Nov 2018 11:29:11 -0500

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.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 12:21:35 -0500 (EST)

On Fri, 30 Nov 2018, Ted Lemon wrote:

> Suppose you have a company that has a subdomain that's internal (this is the case where they control the delegation).   The way you make this work is that you publish a signed delegation to the internal
> zone.

That means your public DNS zone must be signed for your internal DNS
zone to be signed? Otherwise you cannot have this signed delegation?
That would mean you cannot run DNSSEC internally before you run it
externally.

>   When you look things up in that zone outside the firewall, you get NXDOMAIN for everything but the SOA on the zone, which returns an old serial number.   Inside the firewall, they get answers, which
> are signed, and which validate.   There's no need for a special trust anchor here.

This scheme seems to require both inside and outside zones are signed
with the same key, or as Mark pointed out, both internal and external
zones need to share their DS records and keep these in sync. As these
are usually different organisations/groups/vendors/services, that is
an actual management problem.

I do not think a protocol should require this manual effort, or add
requirements for where to run DNSSEC first in an organisation.

> So that works if the zone being queried is just nonexistent outside the firewall.   If the zone looks different outside the firewall than inside the firewall, it's a bit more complicated, but essentially
> similar.

With similar problems as above.

>   There are two ways to approach this.   One is to assume that the validator never checks the SOA on the zone.   This is almost certainly the case for nearly any use case.   In that case, you just
> run the internal and external name servers with the same ZSK, and have a delegation above it.   You don't worry about zone serial numbers, because they don't affect validation.   When you're inside the VPN,
> you get answers for the internal zone; when you're outside the vpn, you get answers for the outside.   Both validate, because the DS record(s) are referring to the same ZSK(s).

coordinating shared ZSK's is even harder then requiring sharing DS
records! ZSKs roll every month, and a lot of software auto-generates
and performs the roll without any humans involved. It seems extremely
fragile to need to coordinate ZSKs between different organisations,
be ready for the same algorithm rollovers, etc etc.

> So in this case, there is no need for a special trust anchor, and using one makes you substantially less secure, and hence is not something we should be advising.

I think your proposal is far to fragile to suggest in real enterprise
deployments.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Fri, 30 Nov 2018 12:30:06 -0500 (EST)

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