Re: [DNSOP] Fwd: NewVersion Notificationfor draft-mekking-dnsop-auto-cpsync-00

-----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-bounces@ietf.org [mailto:dnsop-bounces@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-----