[Dnssec-deployment] Signed TLD status
Ed.Lewis at neustar.biz
Tue Sep 28 14:31:11 EDT 2010
At 10:51 -0500 9/28/10, Anthony Iliopoulos wrote:
>and that of course, changes the scenery significantly. In all
>previous discussions, the basis is that there is a dangling DS
>in the parent, no matching DNSKEY in the child, and no other
>DS/DNSKEY pair available for authentication, and that's a very
What has to be made clear is that the unit of weight here is the
cryptographic algorithm. A dangling DS is not a problem if there's
another DS of the same algorithm that is non-dangling.
>for DNS. I don't agree that security should not be tightened. "Lock
>step rhythm" is just a generalization, but in reality there are several
>timing considerations to be taken into account, which are unfortunately
>part of the deal, and perhaps somewhat hard to get right. Indeed, it
>makes DNS break in new ways, but that means that everyone needs to pay
>closer attention to TTLs and proper timings.
I would love tighter security too. Given that my day job has other
priorities I am unable to get a strict proof why DNSSEC is optimal
for the problem it is set to solve. Other security suggestions can
be raised, debated, and rated as they come. Your mention "timing
considerations" and "break in new ways." That's the consequence of
tightenings that have been suggested.
>I could also claim that securing without really securing is equally
>useless. How can a validator ever assure that a reply is provably
>insecure, unless there are strict validation rules in place ?
DNSSEC isn't about replies (or responses), it is about data
protection and specifically a protection for the cache. DNSSEC does
have strict validation rules in place - but short of mandating every
zone in the world be DNSSEC we have to handle the situation in which
data may not have an associated, authorized signature. And that
makes it look loose.
If we tighten that, we crack the distributed management of the system
by requiring a new level of pain for all involved.
>Still, I think that it really depends on what you expect out of
>the actual DNSSEC assurance. If we are talking about name-to-ip
>mapping guarantees, then apparently it is not very interesting
>to have such rigid rules. The expectation is to leverage DNSSEC
>assurance for other protocols outside DNS though. Things like SSHFP
>are more naive forms of it, other things, like the ietf-keyassure
>efforts, are pointing towards something far more serious.
8 years ago the IETF had a BoF on that (SYKED). One of the problems
that prevented this idea from mushrooming is that you are placing
more and more trust in the DNS administration (person, role, or
procedures) than applications would want to place. E.g., we have
separate groups managing the DNS infrastructure and the email
infrastructure. The email people wouldn't be happy if mail stopped
flowing because the DNS administrator forgot to refresh the
signatures one day. What if all you had to do was "social engineer"
the DNS admin to undercut the security of an entire organization?
NeuStar You can leave a voice message at +1-571-434-5468
Ever get the feeling that someday if you google for your own life story,
you'll find that someone has already written it and it's on sale at Amazon?
More information about the Dnssec-deployment