On Tue, 27 Nov 2018, Joe Abley wrote:
On 27 Nov 2018, at 10:02, Tony Finch <d...@dotat.at> wrote:
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.
As currently no one is able to do internal DNSSEC zones and VPNs, I
cannot agree that is is premature or unhelpfully specific. It is a real
solution to a real problem. Regardless of any generic solution, you end
up with the same kind of considerations we reached here. A whitelist
of zones that is securely provisioned and not dynamically updated, and
flexibility to roll your internal trust anchor without locking out all
your [VPN] clients from accessing internal resources.
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).
When installing provisioning profiles, eg Apple tells you things like
"this party can monitor everything you do, are you sure you want to do
this". I don't think there is anything more you can do than that.
Although if there is, clients can apply those additional security
measures as local policy. For instance, a phone or laptop that is
under Enterprise Management could forbid DNSSEC_TA installations
outside of their signed profiles. Or a phone could decide DNSSEC_TA
installations will only ever be accepted when under Enterprise
management control. This draft does not forbid any of these kind of
decisions.
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.
Yes they can. Netflix could send you a provisioning profile that says it
wants to MITM gmail.com. You could install that because you trust
Netflix. Trust is part of a company's success. Let's hope trustworthy
companies won't screw around like this. Note also these companies
already can trick people into install Root CA's, so this is basically
a minor variant of the power they already have to subvert endusers.
Sure, people are tricked in installing Random Inc things. They will
click okay on any warning. Those people are beyond help. Yes we
could not allow enterprises to have DNSSEC (which is basically what
you say when you do not allow them to rollover keys indepedently of
the VPN configuration) but that would be a tragedy of the commons.
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.
VPN users cannot always update their provisioning on the spot, without
being on the VPN already. VPN users often don't use the VPN for months,
and only use it when traveling for example. Like on a dedicated travel
phone. Your suggestion of hardcoding TA keys is imply impractical and
won't fly in real operational deployments. It is extremely fragile. Having
restrictions on the whitelist was already a compromise. Originally,
the draft let IKE update the white list too. We (reluctantly) decided
that we didn't want one compromised VPN device to be able to install
malicious DNSSEC_TA's. So we limited the whitelist update to a (hopefully
more secure) provisioning system.
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.
If browsers create that painful world of overriding the OS, they will
need to solve that. That is very far out of scope for this VPN draft,
and we cannot stall this document for the multi-years discussion on
DoH and DOT impact on overriding random DNS trees at whim, by users
being ticked into configuring certain DoH/DOT servers. The problem is
similar in nature, but totally orthogonal.
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.
I think DNSOP needs to realise that DNS VPN configuration is going to
happen. With DNSSEC it is going to happen. We need to come up with a
solutation that seems least scary while still being deployable. Simply
saying no won't change the draft. If the draft doesn't change or is
blocked by this, non-standard or draft solutions will be used leading
to the same undesired outcome plus vague standards.
I still believe the current draft describes the most strict, while still
being usable, solution. I'm all up for smarter ideas from smarter people,
but we have already sat down with a bunch of security people back at
IETF 100, including the ADs and IPsecME chairs, and couldn't come up
with something better than the current compromise proposal.
Note that formally, the DISCUSS that triggered this was marked as
resolved by Warren. I'm happy to discuss this for a bit longer if
we are trying to build something that might be better. But we have
done Early Code Points already so at some point we have to stop
discussing and publish with the rough consensus.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
