[Dnssec-deployment] accepting DS vs DNSKEY

[Olafur Gudmundsson]

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 
enterprises/universities/etc.


> 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 
parties policies/mistakes.

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
> dns-operator--registrant--reseller--reseller--registrar--registry
> 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.

	Olafur