Subject: [ietf-provreg] secdns draft

From: Klaus Malorny <[email-masked]>
Date: Tue, 25 Oct 2005 18:49:50 +0200

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
      [email-masked]             Tel. +49 231 9703 0

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Oct 2005 10:38:59 -0700

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

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

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

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.

>   We don't have an "urgent" for NS records neither :-)

Hmmm, I forget.

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

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

---

From: Klaus Malorny <[email-masked]>
Date: Tue, 25 Oct 2005 21:02:01 +0200

Edward Lewis wrote:

> 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.
> 
> time.  But never sign the DS set for more time than the prudent/agreed 
> upon lifetime duration.
> 

Thanks for the clarification. I thought the most simple solution to revoke a 
key is to remove it from the zone, as it would break the chain of trust also. 
But I have to admit that I am not yet fully aware of the effects of the various 
caching mechanisms on the time a resolver can falsely assume the correctness of 
a revoked key. I have to check that.

regards,

Klaus

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 Oct 2005 12:05:45 -0700

At 21:02 +0200 10/25/05, Klaus Malorny wrote:

>caching mechanisms on the time a resolver can falsely assume the correctness
>of a revoked key. I have to check that.

One issue I omitted is that there is also the possibility of an 
illicit replay attack.  Besides caches, if the attacker copies the DS 
set before the key compromise is known, the attacker can poison 
caches with the set as long as the signature is valid.  So even 
pulling the (DS record of the) key from the parent zone isn't 
sufficient for revocation.

Short of having an explicit revocation list in DNS (never happen), we 
have this problem.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

True story: