[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "Klaus Malorny" <Klaus.Malorny@knipp.de>, <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Tue, 25 Oct 2005 13:35:00 -0400
Content-class: urn:content-classes:message
Sender: owner-ietf-provreg@cafax.se
Thread-Index: AcXZiKye8z6NN34xTkGp3jwIvLdMrQAAKWEg
Thread-Topic: [ietf-provreg] secdns draft
Subject: RE: [ietf-provreg] secdns draft

Klaus,

You should really read the mailing list archives of the dnsop working group.  Everything you're asking about was discussed there over the course of several months before the document was approved by the IESG.

-Scott-

> -----Original Message-----
> From: owner-ietf-provreg@cafax.se 
> [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Klaus Malorny
> Sent: Tuesday, October 25, 2005 12:50 PM
> To: ietf-provreg@cafax.se
> Subject: [ietf-provreg] secdns draft
> 
> 
> 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
> 
> 
> 
> 


Home | Date list | Subject list