-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephan,
There were acknowledged some drawbacks of using DNSSEC as the security channel in this specific case. One is that you still do not cover unscheduled key rollovers, as that event may occur as a result of a compromised key. It is possible to cover if you use a different security channel, as is described in the section 'Security Considerations'. Another drawback is that a proxy parent (for example the registrar) might not have the appropriate material available to use DNSSEC verification. Also, the intention of the memo is to provide a more general solution to synchronize records between child and parent, which covers all required records (not only DS) and can be used in all situations. Best regards, Matthijs On 06/29/2010 05:15 PM, Stephan Lagerholm wrote: > Hi Wolfgang, > > My concern was not about the updates but rather about the gigantic > number of keys a busy parent would have to create, revoke, store, renew, > etc. > > It doesn't make sense to me to utilize symmetric encryption (such as > TSIG) to solve this problem. A scheme that utilized an asymmetric key > would be a much better fit. DNSSEC itself would be a strong candidate > here. > > Thanks, S > ---------------------------------------------------------------------- > Stephan Lagerholm > Senior DNS Architect, M.Sc. ,CISSP > Secure64 Software Corporation, www.secure64.com > Cell: 469-834-3940 > >> -----Original Message----- >> From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf > Of >> Wolfgang Nagele >> Sent: Tuesday, June 29, 2010 9:44 AM >> To: Stephan Lagerholm >> Cc: dnsop@ietf.org; Matthijs Mekking >> Subject: Re: [DNSOP] Fwd: NewVersion Notificationfor > draft-mekking-dnsop- >> auto-cpsync-00 >> >> Hi Stephan, >> >>> I like this draft but I'm a little bit concerned about the > scalability. >>> How will a busy parent provision a unique secret key for each of the >>> child? >> Do you mean the scalability for capacity on the update server side? >> Although >> BIND might not be able to scale this out of the box, the example has > only >> been >> given in the draft to have a hands-on way for ppl to try this draft. >> >> In reality it should not be a major issue to receive those DNS updates > and >> process them (with or without signatures) - similar efforts are > currently >> made >> for each request to change NS-sets on the parent (admittedly those > might >> happen >> less frequent). >> >>> And how will this key be transported between the parent and the >>> child in a secure way? >> The same way a parent is currently providing a domain owner with >> credentials for >> their management interfaces. If a domain owner has specific > requirements >> in >> terms of security on that channel it is something where registrars can >> offer >> whatever their customers demand. >> >> Regards, >> Wolfgang >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJMK39zAAoJEA8yVCPsQCW5dPQIAMrzIXKfb3CnhCeAaZA5K6h7 RxLHEnCTh/NQvvFEOTWL+3zeBPP1CL3GO0meXFTUNw7e8kvjmKp7HvYz/3sHafFt y6wbSmWfWCTgfXbDQfPXd3yxeY1JJBnDWfEbPISvYytB3AIV2YkfXSwa/OtpiFxz FehVVToLllLARqMEpRuG+EWZZtEojDaPbJfDhyongixwPpaqD3nBzc9tnTkZIUby 4Ld0XZ+6pnBQdIIHXsulf7RxN/0uvwTR0PblLM38mmKB+nd4jebXsm4FjGiIX7zr k6PXUQsoJdnAsa+TO4+ZF+/7Vl7IolYQo3O5D+3qwd30gWXSmwZxzgVN9NBw/7g= =JkPp -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
