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

[Ted Lemon <[e-mail]>]

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 <[e-mail]> wrote:

> Ted Lemon <[e-mail]> 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  <[e-mail]>  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.
>