[Dnssec-deployment] accepting DS vs DNSKEY

[Thierry Moreau]

Dear all:

I reply to Ed's question below, but my point is a broader observation.


Edward Lewis wrote:
> 
> 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?

For all practical purposes, the fear of broken hash should not bother 
anyone involved in actual DNSSEC deployment. It is already accounted 
for, and by a good enough margin, by the root/TLD practice of using 
SHA256 for their own signatures. A TLD registry rejecting SHA-1 in DS 
records in the foreseeable future is very unlikely (.gov is an exception 
-- should the whole world abide by their policy?).

More generally, this whole discussion is yet another example of this 
technical community  unable to provide a simple message about DNSSEC.

The short answer is "It makes no difference whether the secure 
registration from a child domain to a parent uses the DNSKEY or DS data 
format." So, as a DNS actor, you may want to support both, or just adapt 
to the limitation imposed by your partners.

Anyone can make a DS data element from a DNSKEY data element (plus maybe 
the hash algorithm indication if not obvious by the context), and there 
is no policy implications in doing so. Anyone can validate the DNSKEY-DS 
relationship. The computational load for doing either make or validate 
is not significant.

I guess the technical disagreement comes from the fact that it makes no 
difference combined with some obscure addiction to endless technical 
discussions in the minds of typical Internet protocol experts, but who 
am  I to tell? Don't you think the quiet audience of this list deserves 
better.

Regards,

- Thierry

   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.)


-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. +1-514-385-5691