[Dnssec-deployment] accepting DS vs DNSKEY

[Edward Lewis]

At 11:53 +0200 5/5/11, Antoin Verschuren wrote:

>1. suppose some time in the future, a registry wants to change policy,
>and not accept DSes with certain algorithm hashes anymore. If the
>registry posseses the DNSKEYs in their DB, this transition is much
>easyer to process than trying to request new DSes from ALL childs. the
>latter transition will take ages if they succeed at all.

My first reaction is "how realistic is that?"  I'm not an expert in 
cryptography so I'm asking this as a request for information - 
regarding the fear over hash algorithms being "broken", can this 
apply to a situation in which the source data is so small and the 
proposed forgery is also small and constrained?  This is the basis of 
my "is this realistic" because I can't imagine any rational registry 
banning the use of a hash for the DS.

Secondly, if this were to happen, and you can't get the new DS 
records there are a number of options.  One is to resort to what I 
consider really poor behavior and "scrape" the DNSKEYs from the 
non-responders.  Two is to consider a non-responsive manager as "now 
running insecure" and simply delete the DS records that offend with 
no replacement.

>2. In a secure DNS operator change, the registry needs to relay DNSKEY
>information from the gaining operator to the loosing one. You cannot
>extract a DNSKEY from the DS, AND there is no secure delegation to the
>gaining operator yet at this stage in the process, so the registry needs
>to additionally request this DNSKEY information from the gaining
>operator. So why not do this at all times, so there is as little as
>possible expensive and complicated child-parent interaction. (child to
>parent interaction needs to follow the
>dns-operator--registrant--reseller--reseller--registrar--registry
>administrative path, as this is the only other secure path which is not
>allways equally reliable).

Why does the registry need to play a role in this?

If the losing operator is not cooperating, the private key is not 
useful, hence the DNSKEY of its public key is not all that important.

And, if the zone's owner really needs this, they can always maintain 
a list of the keys the operator has been using.

>3. Hashing a DNSKEY takes far less time than generating signatures for a
>secure delegation, so the scaling argument is not valid.

Hashing the key + Signing the delegation > Signing the delegation

Remember, hashing means also know what key to hash.  Not all SEPs 
have to be in DS records.

>Just trying to put real world operational examples.
>I'm happily convinced otherwise.

I'm not sure of that.  Anyone can concoct a situation in which they 
can justify the submission of DNSKEY.  None of the justifications 
will be based on protocol needs.  Anyone can say "national policy 
requires we hold all keys" and thus you want the DNSKEY submission - 
but this is not a requirement that has anything to do with the DNS 
protocol and the security extensions.

If you're happy with doing only what is tied to the protocol, you 
don't want to over engineer by requiring the DNSKEY.

Looking back again - in the early days of DNSSEC we had "key at 
parent" and other transfers.  While we held to these models, from 
1996-2002 we spun our wheels in workshops until the DS came along to 
"break" the transfer of key material (and some other problems).  If 
transferring the keys worked, we'd be working from RFC 2535 and not 
RFC 4033.  (Ok, other things were fixed too, but the delegation point 
treatment was one of the big issues.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Me to infant son: "Waah! Waah! Is that all you can say?  Waah?"
Son: "Waah!"