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" <dnsop-boun...@ietf.org
on behalf of p...@nohats.ca> 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.)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
