Re: [ietf-provreg] secdns draft

[Edward Lewis <Ed.Lewis@Neustar.biz>]

At 18:49 +0200 10/25/05, Klaus Malorny wrote:
>Hi all,
>
>I just browsed through Scott Hollenbeck's secdns EPP extension draft. While it

It's not "just" a draft, it's in the RFC Editor Queue. But it is 
never too late to ask questions.

>* 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?

The discussion of this happened in a DNSOP meeting in March of this year.

The lifetime of a signature is a parameter that:

1) For the benefit of the registry be lengthened to reduce the amount of work
    needed.

2) For the benefit of the registrant by shortened to limit the time in which
    a cryptographic accident causes damage.

Because of the contradicting goals, we figured the parameter is 
needed in the protocol.

To explain #2.  Imagine a registrant creates a key and the (DS data 
representing the) key is sent to the registry.  If the registrant's 
private key is then "stolen/guessed/exposed", the party that has 
gained illegitimate access to the key can abuse the key as long as 
the DS record is seen as valid.  So, shortening the DS record means 
the window of vulnerability is lessened.

The TTL record value was also considered, but the DNSSEC specs (RFC 
4034, etc.) already specify the TTL value.

>related to the above:
>
>** what should the registry do at the end of the lifetime?

The lifetime is relative.  If there is no change, just regenerate the 
signature over the DS record.  When to regenerate a signature is a 
deeper topic - some suggest regenerating signatures about 1/2 way 
through the lifetime just to be sure the signatures get out there in 
time.  But never sign the DS set for more time than the 
prudent/agreed upon lifetime duration.

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

Your call.  If you are nice to the registrant, pick the minimum.  If 
you want to lessen your CPU pick the maximum. ;)  I think this isn't 
so much an interoperability or protocol issue, but a business 
decision.

>* 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 :-)

Hmmm, I forget.

>* 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.

Not many do.  Although I feel that the DS data is all you want to 
transfer, the protocol schema is written to be more flexible for 
those who disagree with my view. ;)  I say that with some sarcasm, 
there are some folks that feel that only the DS record is needed, but 
some others want to have the option to send the key data.  Not all 
registries will have the same business thoughts.


>* 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.

It kind of does.  Some tools will trash a new key that matched 
existing keys (in tag).  But the question remains, I would need to 
think about it more.  Either way you go (delete all, refuse to accept 
the key at all), something workable will be found.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

True story:
Only a routing "expert" would fly London->Minneapolis->Dallas->Minneapolis
to get home from a conference.  (Cities changed to protect his identity.)