[Dnssec-deployment] accepting DS vs DNSKEY

[bmanning at vacation.karoshi.com]

Ed stipuated "a good arguement"... :)

wrt point#1,  all bets are off the table if one involkes local policy.
a registry may change its policy to not accept registrations from people
with unless they have A/B blood type only.   End of the day, the question
becomes one of who owns your data, you or your parent?

point#2 is a reflection of an ICANN implementation artifact and has little
to do with the DNS protocol.

point#3 might be true.  

/bill

On Thu, May 05, 2011 at 11:53:33AM +0200, 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.
> 
> 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.
> 
> 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).
> 
> 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.
> 
> - -- 
> Antoin Verschuren
> 
> Technical Policy Advisor SIDN
> Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands
> 
> P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
> mailto:antoin.verschuren at sidn.nl  xmpp:antoin at jabber.sidn.nl
> http://www.sidn.nl/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
> 
> iQEcBAEBAgAGBQJNwnOdAAoJEDqHrM883AgnjkkH/jA4u856n2V9KVX6t7YpwXSL
> PxtyqTRwFhmkw/FIu4h1hnM3G88Lpl0lS7vKNYwTNlC8anVy/KDddKr76diCtlo1
> WgjsCrDiQ/AH4bHia0uXwtPyhDuXffW27eC+XivwQvkYHGcG8lhHfMWPc2jrIE82
> Zm7WyQoLUpWpT/MlR/e6eTlmlLT0EXTdIMtuqVIbbTPZebwmtPjb1EIurQyB8cLG
> pBKpk3CWyW9UjIeFtHWu3gydFk45HCEPZMFg13hNkt0uhtkB2bIH38eIRcExVW4E
> pFUsawHsHGGD9miBhxQWC/9MLChDZ456+klTsYzfvoxwPYnDbfxNuomPAjG4Fcc=
> =QI7U
> -----END PGP SIGNATURE-----