Subject: Re: [DNSOP] Comment on draft-livingood-dnsop-negative-trust-anchors-01.txt

From: Tony Finch <[email-masked]>
Date: Sat, 1 Nov 2014 14:35:00 +0000

Brian Dickson <[email-masked]> wrote:

> For anyone using an open, well-known resolver (either provided by their
> ISP, or operated as a "public service"), include instructions on use of a
> provider-specific DLV and provider-specific "alternative trust anchor
> (DNSKEY)".

I think your suggestion will only work for botched key rollovers. The
other common failure is expired signatures, which you could only fix DLV
style if your ISP resolver dynamically re-signs all answers in the zone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Cyclonic in northwest, otherwise mainly northerly or northwesterly
5 or 6. Slight or moderate. Showers in northwest. Good.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 1 Nov 2014 19:30:53 -0400

On Fri, Oct 31, 2014 at 8:17 PM, Brian Dickson
<[email-masked]> wrote:
> I think it is good to minimize disruption caused by broken DNSSEC domains,
> for all the reasons listed in the document.
>
> However, I also believe there is a second-order negative effect of
> implementing NTAs as described.
>
> Validating stub resolvers and validating forwarding resolvers, will still
> break.
>

Yup. This is a feature, not a bug.

NTA only makes the local / "ISP resolver" not perform validation for
the domain. Anyone "downstream" who is doing validation will still
perform the validation, and this will fail -- this is, IMO, the right
thing to have happen.
Downstream validators are presumably a: more security conscious and b:
more able to troubleshoot DNS issues than my auntie.

There is a big difference between handing back an answer as though you
are not a validator (the NTA), and signing someone else's answer.

W

> I do have a suggestion, which I hope is worth exploring and considering.
>
> For anyone using an open, well-known resolver (either provided by their ISP,
> or operated as a "public service"), include instructions on use of a
> Whenever it is necessary to over-ride broken DNSSEC zones, most likely on
> the Secure Entry Point, do the following:
> (1) Add a KSK to the apex DNSKEY RRset. For convenience use the same KSK for
> all such instances, and publish the public DNSKEY used.
> (2) Sign the apex DNSKEY RRset with this new KSK
> (3) Add this KSK into the DLV operated by the resolver operator at the
> appropriate location. For example, if example.com is broken, put the KSK at
> example.com.dlv.example.net, if the operator of the public resolver is
> example.net.
> (4) Observe successful validation of example.com by anyone configured to use
> dlv.example.net as their DLV.
>
> I haven't tried this, and there might be some specific modifications to what
> I described needed to make the configuration correct/functional. I don't
> believe it introduces new insecurities to anyone who already has placed
> trust in the resolver at example.net.
> (Is it the case that things that use DLV validate the chain of trust to the
> DLV itself, from the root, if there is not a separate trust anchor for the
> DLV zone? That would be optimal, security-wise, I believe.)
>
> Thoughts?
>
> Brian Dickson

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Brian Dickson <[email-masked]>
Date: Sat, 1 Nov 2014 20:30:45 -0700

Sent from my iPhone

> On Nov 1, 2014, at 4:30 PM, Warren Kumari <[email-masked]> wrote:
> 

There is subtlety in using DLV instances.

On the one hand, passing along answers that have known DNSSEC validation problems avoids blocking your auntie.

On the other hand, if it is known to have problems, stitching things up in ways that still don't validate without use of DLV isn't really any worse.

And on the gripping hand, adding the fix in DLV, for only those who have configured that specific DLV, means those clients are able to validate.

Furthermore, those doing advanced level DNS operations are unlikely to use NTA implementer services.

And, IMHO, advanced operators could signal a desire for unmodified answers the traditional way, via the CD bit.

Adding the DLV function provides a scaling benefit in terms of how many validating forwarders need to make the NTA mod to resolve the affected domain. Without DLV, there is still an incentive to turn off validation -- which is what NTA is explicitly trying to prevent.

Having forwarders validate should be something we all encourage and support, especially in this sort of document.

I definitely think it is up to each operator as to whether they do this.

However, I would like this to be included in the draft as an optional aspect of setting up NTAs, so that operators can evaluate the pros and cons, and make informed choices.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Tue, 4 Nov 2014 15:07:40 -0800

TL;DR

As Tony Finch observed, the benefit is only seen when SEP failures occur,
most often in key-rolls. I'd argue that the vast majority of observed
DNSSEC failures have been of the key-roll (or initial set-up) variety with
mismatches between DS and DNSKEY, but otherwise properly signed (by ZSK)
zones.

Also, my assumption about what is needed to fix this (beyond NTA) was
WRONG. :-)
(It is amazing what you learn by setting up test cases and observing
behavior. Also, "delv" rocks.)

The good news is, for most cases, setting up a DLV-based "fix" can be done,
with only the DNSKEY(KSK).
I.e. modifying responses is not required AT ALL, and no new DNSKEYs or
signatures are needed.

(Please ignore my previous responses.)

Long version:

In order to assist validating forwarders, broken DNSSEC zones can be
"repaired" using DLV, and ONLY DLV.

Take the result of "dnssec-dsfromkey" for the apex KSK, append the DLV
domain name to the owner names.
Insert into the DLV zone, sign, bazinga. Use of this DLV, with the modified
suite of bind tools, securely resolves.

As currently implemented in BIND-9.10.1, a modification is needed to
lib/dns/validator.c.
The good news is, it is a one-line change.
Basically, it changes the logic, if no DS->DNSKEY validated match can be
made, to fall through to use DLV.

(In the current logic, DLV is only queried if no DS exists above a secure
zone, from a secure zone. The change extends the logic to make this "no
VALID DS" instead of "no DS".)

No changes to the answers served by a resolver (who is the target of
forwarders) are required.

There is not even a requirement that the NTA resolver operator be the
operator of the "fix-up" DLV.

Given the relative rarity of DNSSEC failures which do not get fixed quickly
enough relative to their perceived value, it may be worth asking for
volunteers to run one (or more) centralized fix-up DLV instances.

So, other than the operational implications to downstream validators of
NTA-implementing resolvers, it may be sufficient to add the observation
regarding DLV as a possible way of fixing broken DS->DNSKEY (on a
third-party basis) as a sub-paragraph.

Hope this helps, and is worth consideration for addition to the draft.

Suggested text and location: New paragraph just before the last paragraph
of section 8:

In addition to configuring a Negative Trust Anchor, implementors MAY choose
to also

implement a DNSSEC Lookaside Validator (DLV) zone, containing appropriate
DNSSEC
material to provide an alternative Secure Entry Point (SEP) into affected
zones.

Individual DLV records consistent with apex KSK records at the
corresponding DLV name,
when referenced by validating resolvers (and/or forwarders), permit DNSSEC
validation
of the affected zone(s). Such DLV registries may be operated by NTA
implementors,
or by other (presumably trustworthy) parties.

(If anyone wants a suite of test zones demonstrating the before/after
behavior, I am more than happy to provide them. Perhaps they would be
useful in another Appendix?)

Brian Dickson

The patch needed for 9.10.1 (which may work on other bind branches) is as
follows:

*diff --git a/lib/dns/validator.c b/lib/dns/validator.c*

*index 88bfaef..31e9425 100644*

*--- a/lib/dns/validator.c*

*+++ b/lib/dns/validator.c*

@@ -2274,7 +2274,8 @@ validatezonekey(dns_validator_t *val) {

        } else {

                validator_log(val, ISC_LOG_INFO,

                              "no valid signature found (DS)");

-               return (DNS_R_NOVALIDSIG);

+               return (startfinddlvsep(val, val->event->name));

+               /* WAS return (DNS_R_NOVALIDSIG); */

        }

 }

On Sat, Nov 1, 2014 at 8:30 PM, Brian Dickson <[email-masked]
> wrote:

> On the other hand, if it is known to have problems, stitching things up in
> ways that still don't validate without use of DLV isn't really any worse.
>
> And on the gripping hand, adding the fix in DLV, for only those who have
> configured that specific DLV, means those clients are able to validate.
>
> Adding the DLV function provides a scaling benefit in terms of how many
> validating forwarders need to make the NTA mod to resolve the affected
> domain. Without DLV, there is still an incentive to turn off validation --
> which is what NTA is explicitly trying to prevent.
>
> Having forwarders validate should be something we all encourage and
> support, especially in this sort of document.
>
> However, I would like this to be included in the draft as an optional
> aspect of setting up NTAs, so that operators can evaluate the pros and
> cons, and make informed choices.
>
> Brian
>
> >
> ISP,

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Nov 2014 11:18:52 -0500

A couple of remarks below:

On Nov 4, 2014, at 18:07, Brian Dickson <[email-masked]> wrote:

> The good news is, for most cases, setting up a DLV-based "fix" can be done, with only the DNSKEY(KSK).
> I.e. modifying responses is not required AT ALL, and no new DNSKEYs or signatures are needed.

Recall that DLV is a registry and thus has all the inherent risks of any registry.

> (Please ignore my previous responses.)

That will cost you plenty, you’ve posted a lot through the years.

;)

> Long version:
> 
> In order to assist validating forwarders, broken DNSSEC zones can be "repaired" using DLV, and ONLY DLV.

Assuming that the problem lay in the keys available to build the trust chain.

> Take the result of "dnssec-dsfromkey" for the apex KSK, append the DLV domain name to the owner names.
> Insert into the DLV zone, sign, bazinga. Use of this DLV, with the modified suite of bind tools, securely resolves.
> 
> As currently implemented in BIND-9.10.1, a modification is needed to lib/dns/validator.c.

In BIND (only), no?  (Well, yes, just an annoying way to say that there are other implementations.)

> Basically, it changes the logic, if no DS->DNSKEY validated match can be made, to fall through to use DLV.

This harks back to something I looked up just today - section 2.7 of RFC 3008 - which restricted the signer ID in the SIG RR to be the name of the zone apex.  Here you are not changing the signer ID but the authoriative source of the zone apex key set.  In the spirit of “any trusted chain in a storm” you have to make sure you can trust the “alternate source.”  Hence my remark above that DLV is a registry with the inherent risks of a registry.

> (In the current logic, DLV is only queried if no DS exists above a secure zone, from a secure zone. The change extends the logic to make this "no VALID DS" instead of "no DS".)
> 
> No changes to the answers served by a resolver (who is the target of forwarders) are required.
> 
> There is not even a requirement that the NTA resolver operator be the operator of the "fix-up" DLV.
> 
> Given the relative rarity of DNSSEC failures which do not get fixed quickly enough relative to their perceived value

I have an experience that says “perceived value” is in the eye of the beholder.  For a while “$we” turned on DNSSEC validation.  When one, tiny, low-query-volume, corner-of-the-internet, zone “broke” we got a trouble ticket.  That ended the validation experiment (the front-line didn’t know the code base in use had NTA).  Didn’t matter that it wasn’t a marque zone, just one that someone who’d bother to complain wanted to get to.

The point is, if the front-liners knew how to uss the NTA, they’d still be using DNSSEC.  Because they wouldn’t have feared the trouble ticket and, while running, would have gained experience and confidence.  That’s been lost.

> , it may be worth asking for volunteers to run one (or more) centralized fix-up DLV instances.

I become scared of you when you start talking about “(or more) …DLV instances.”  In the same sense that more X.509 certificate authorities degraded the trust in X.509 chain building, more sources of data to build trust chains hasn’t had a good track record.

> So, other than the operational implications to downstream validators of NTA-implementing resolvers, it may be sufficient to add the observation regarding DLV as a possible way of fixing broken DS->DNSKEY (on a third-party basis) as a sub-paragraph.

IMHO, under the banner of “local policy” (as evidenced in 2.7 or RFC 3008 and elsewhere), a local determination to press the NTA button in an implementation is well within what an operator should want.  Adding in untold other sources to an implementation is not within the spirit of “local policy” (beyond deciding to use or not the implementation) - on par with some recent OS release apparently deciding to store private documents on it’s cloud service “for safe keeping.” ;)

Dropped the rest of the mail thread here…