On Tue, 13 May 2014, Ben Laurie wrote:
The legitimate owner can tell - that's the point, right?
How does that help protect a non-owner user of someone's site being
attacked with a targetted attack? If I don't run victim.com, and I am
just a visitor of victim.com, but only I am given rogue DNSSEC records,
how can I tell something is wrong? I would go to the public log and see
the DS I received is not in there?
Right, exactly.
So how does the owner authorize a new DS in such a way that the parent
could not override?
I'm reminded of the dlv.isc.org setup, where the zone owner had to prove
control of the private key by publishing something in the zone. In a way
this is also similar to the DS update problem in general. A rogue/hacked
registry could also perform a DS update.
I'm still not sure how to prevent a rogue update in the CT. And once you
fix the rogue update problem, you face the reverse problem. A zone
legitimately changes ownership and the old owner is malicious. How do
you deal with that?
Adding transition time into the equation could address some of this,
but that will re-add the pinning problems.
And adding another kind of authentication key would be adding similar
problems as with TACK.
Maybe some of these attacks are just out of scope and unfixable. After
all, most domains are not "owned" but wrapped in legalese to really only
give me a limited lease on it.
In that case, we could do things like "warn if a DS is present in the DS
RRset that has not been logged into the CT with a known signature by a
current KSK" and "zone cut changed KSK". I'm just not sure how many
false positives that would give with people rolling keys too fast for
the CT log (and slow enough to indeed give that added protection).
The last thing we need is another "cert patrol" style avalanche of
popups.
Paul
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
