Re: [DNSOP] [Ext] Re: Configured Trust Anchor vs. DS record

[Edward Lewis <[e-mail]>]

To begin...thanks, Frederico, I was trying to find that case but had forgotten which ccTLD was involved.  (Web searches failed me...)

On 11/14/17, 23:11, "DNSOP on behalf of Paul Wouters" <[e-mail] on behalf of [e-mail]> wrote:

>    On Wed, 15 Nov 2017, Frederico A C Neves wrote:
>    
>    > Yes. And add to that cases were TLDs rolled just before adding to the
>    > root.
>    
>    So what is the security model then?

Keep in mind that DNSSEC is enabling the receiver to validate the DNS protocol was followed.   (Including, if the DNS has bad data in it, the bad data is protected.)
 
>Let's say .example rolled and now has a bad DS.

This has happened a number of times already.
    
>Someone overrides this with a local trust anchor so the domain does not go dark.

Or configures a negative trust anchor.

>- How do you know the roll was legitimate?

In-band, you can't tell.  But word of mouth speeds quickly, for better or worse.  One quip from one case was "twitter is faster than nagios!"

(I don't know how a DNS message receiver would realize/detect a roll, outside of STD 69's automated updates process.)

>- How does an application make a security decision about a found TLSA record that depends on this trust anchor?

That is a matter for the application, not the DNS.

...

>Now same as above, but one of these rolls were done by an attacker and is malicious.

I am scratching my head a bit trying to first imagine a validator even detecting a key rollover, legit or not.  As it is now, caches are fickle, if what's cached doesn't have the key needed, they SERVFAIL the answer, not get a new copy of the keys (because of rollover-and-die, an issue documented many years ago).  They don't distinguish between a botched rollover and someone one-time forging a response.

>Trusting "any"thing is just a path to madness.
 
Not trusting anything is a path to paranoia. ;)  Madness or paranoia...

The case for "any" trusted chain is rooted in the desire to retain as much robustness when slapping on security.  This assumes that the greater issue lies in operational errors than re-delegation of zones.  The track record shows that operator error is the greater source of DNSSEC invalidations, on the other hand, the thought that data gets misdirected is a concern.

Ask this question...when a validator begins to systematically SERVFAIL data, what happens now?  Followed actions include checking DNSVIZ to see if there's a DNSSEC problem with the authority and potentially negative trust anchors being applied.  (This in the response to trouble tickets being lodged, support desk calls, etc.)  With this as the current response, would preferring trust anchors over DS records (to put this problem tritely) be effective?  Once a validator notes a re-delegation, the operator might just open the flood gates and let all the traffic go to the re-delegation anyway.  (Not, myself, understanding if the operator, when adding a negative trust anchor would realize there was a positive trust anchor for the same name.)