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. On Tue, Nov 27, 2018 at 10:38 AM Tony Finch <d...@dotat.at> wrote: > Ted Lemon <mel...@fugue.com> wrote: > > > > 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. > > :-) > > 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 <d...@dotat.at> 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. >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
