[Dnssec-deployment] Signed TLD status

[Edward Lewis]

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
>fine distinction.

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?

Also... http://www.circleid.com/posts/852611_dnssec_adds_value/
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
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?