[Dnssec-deployment] accepting DS vs DNSKEY
Ed.Lewis at neustar.biz
Thu May 5 09:16:11 EDT 2011
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
>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
>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.)
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?"
More information about the Dnssec-deployment