[ietf-provreg] secdns draft

[Klaus Malorny <Klaus.Malorny@knipp.de>]

Hi all,

I just browsed through Scott Hollenbeck's secdns EPP extension draft. While it 
is just another example of an EPP "community driven" standard, being in the 8th 
round already, but mentioned in this list only once yet, and while I still have 
some general concerns regarding the involvement of the registrar and the 
consequences to the actual security of DNSSEC, I don't want to examine this (at 
least now), but I do have some concrete questions regarding the latest (08) draft:

* The draft allows the specification of a value called "maxSigLife". This shall
   allow the registrar to specify the maximum lifetime of the signature of the DS
   record. However, to my (surely incomplete) understanding of the DNSSEC
   standard, the lifetime of an RRSIG signature depends _solely_ on the intended
   lifetime of the related signing key, i.e. in this case the ZSK of the
   registry, which depends on the key length and the rollover strategy chosen by
   the registry and not on the content the RRSIG signs (i.e. the DS record in
   this case). If at all, it would IMHO make much more sense to allow the
   specification of the TTL for the DS record (but this is impossible also).
   So to me, this value does not make any sense. Any counter-arguments?

related to the above:

** what should the registry do at the end of the lifetime?

** what should the registry do if multiple DS records with different
    maxSigLife values exist?

* What is the purpose of the "urgent" value? I see no reason why the registry
   would not include the new DS record in the very next zone update anyway.
   We don't have an "urgent" for NS records neither :-)

* I do not see any sense in specifying both the contents of the DS record
   _and_ the related DNSKEY record at the same time. The DS record can
   be calculated from the DNSKEY (of course), and a registry would have to
   calculate it anyway in order to verify the equality of both parameters.
   To me, it would make more sense to have them as alternatives than of
   having both types at the same time. If a registry policy ever wants to
   check certain key properties (algorithm, key length), then a registry
   can make the specification of the DNSKEY (instead of the DS) mandatory.

* Using the 16 Bit key tag of the key to identify the DS/DNSKEY that
   should be removed from the domain is a bit risky having the probability
   in mind that more than one key has exactly this tag. DNSSEC never relies
   on the uniqueness of this tag.

Just my two cents.

regards,

Klaus


___________________________________________________________________________
      |       |
      | knipp |                   Knipp  Medien und Kommunikation GmbH
       -------                           Technologiepark
                                         Martin-Schmeißer-Weg 9
      Dipl. Inf. Klaus Malorny           44227 Dortmund
      Klaus.Malorny@knipp.de             Tel. +49 231 9703 0