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

[Ted Lemon <[e-mail]>]

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.

On Tue, Nov 27, 2018 at 10:02 AM Tony Finch <[e-mail]> wrote:

> Ted Lemon <[e-mail]> 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.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> an equitable and peaceful international order
>