[Dnssec-deployment] accepting DS vs DNSKEY
ogud at ogud.com
Thu May 5 10:41:20 EDT 2011
On 05/05/2011 5:53 AM, Antoin Verschuren wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 04-05-11 16:28, Edward Lewis wrote:
>> I don't think it is possible to make a good argument for the registry to
>> generate the DS record from a given DNSKEY record.
IMHO it is counter productive to think about this as just communication
between registry-registrant. Think about the general case of
parent-child, as the same issues apply inside distributed
> Ok, let me try then.
> 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.
What about the case where the child wants to have DS with digest
algorithms 2 and 3 and the parent refuses to accept 3?
Currently the DNSKEY extension to EPP does not have any way for child to
indicate preference in DS digests, I know of no way to find out what DS
digests algorithms my parents accept. I know that the registrars I use
for org and com do not accept algorithm 3, but there is no way for me
to tell if the issue is with the Registrar/reseller I'm dealing with or
the registry if I find a DS in the zone that is of algorithm 3 then it
is the front end that has the problem, otherwise I can not tell.
No matter how we slice this, someone is going to be hostage of the other
Also if the parent decides to retire digest algorithm x from their
zone, then there is a the potential that certain number of resolvers my
suddenly delegations as unsigned. Do the parents want that liability
hanging over their head?
> 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).
In the R* world this is a compelling argument but this requires the
submission of the new ZSK to the registry and it is never to be
published as a trust anchor, how the registry tells when there is no SEP
bit on any key.
We can recommend that the new operator use a single key at least in the
beginning as that cuts down on possible things that can go wrong.
> 3. Hashing a DNSKEY takes far less time than generating signatures for a
> secure delegation, so the scaling argument is not valid.
> Just trying to put real world operational examples.
> I'm happily convinced otherwise.
Just injecting the view from the other side.
More information about the Dnssec-deployment