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.
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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
