Subject: [DNSOP] I-D Action:draft-ietf-dnsop-rfc4641bis-04.txt

From: [email-masked]
Date: Mon, 2 Aug 2010 08:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of the IETF.

	Title           : DNSSEC Operational Practices, Version 2
	Author(s)       : O. Kolkman
	Filename        : draft-ietf-dnsop-rfc4641bis-04.txt
	Pages           : 56
	Date            : 2010-08-02

This document describes a set of practices for operating the DNS with
security extensions (DNSSEC).  The target audience is zone
administrators deploying DNSSEC.

The document discusses operational aspects of using keys and
signatures in the DNS.  It discusses issues of key generation, key
storage, signature generation, key rollover, and related policies.

[When approved] This document obsoletes RFC 4641 as it covers more
operational ground and gives more up-to-date requirements with
respect to key sizes and the DNSSEC operations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dnsop-rfc4641bis-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 04 Aug 2010 16:45:49 +0200

> 	Filename        : draft-ietf-dnsop-rfc4641bis-04.txt

This is just a follow up for the discussion in Maastrich on RFC5011 and 
key algorithm rollovers.

I thought of sending the text, but I have re-read the 5011 and it looks 
more complicated :-(.

Just a reminder: RFC4035 section 2.2 says:

    There MUST be an RRSIG for each RRset using at least one DNSKEY of
    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
    itself MUST be signed by each algorithm appearing in the DS RRset
    located at the delegating parent (if any).

RFC5011 sections:

2.1. Revocation

If you have a key A with alg1 and key B with alg2, you:

a) cannot revoke any of the keys
b) we must define that revoked key as an exception to RFC4035 2.2

2.2 Add Hold-Down

Basically same situation.

If you add key C with new algorithm, you need to immediately sign whole 
zone with new algorithm regardless of the hold-down timer.

6.1 Adding a Trust Anchor

The scenario is incorrect in step 4 and you need to follow the procedure 
outlined in draft-ietf-dnsop-rfc4641bis-04.txt

6.2 Deleting a Trust Anchor

Is correct, but it still needs to follow the:

- remove DNSKEY
- wait for DNSKEY TTL
- remove signatures

after step 2.

6.3 Key Roll-over (and 6.4 and 6.5)

If the 'C' has different algorithm then the step 2. and 4. are incorrect.

6.6 Trust Point Deletion

Is incorrect.  If the new key has different algorithm, you need to 
publish DNSKEY first and only after it's there (and expired in caches) 
you can update DS at parent.

So it get's much more complicated.  And you cannot revoke old-keys at 
the same time you add new keys.

Ondrej
-- 
  Ondřej Surý
  vedoucí výzkumu/Head of R&D department
  -------------------------------------------
  CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
  Americka 23, 120 00 Praha 2, Czech Republic
  mailto:[email-masked]    http://nic.cz/
  tel:+420.222745110       fax:+420.222745112
  -------------------------------------------

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 05 Aug 2010 09:38:22 +0200

Hi Ondřej,

On 08/04/2010 04:45 PM, Ondřej Surý wrote:
...
> I thought of sending the text, but I have re-read the 5011 and it looks

I send text, but unfortunately my mail did not reach the dnsop mail list
yet :(

> a) cannot revoke any of the keys

You can, you need temporary 'shadow' keys that have the same algorithms.
So, introduce key A' with alg1 if you want the revoke A and introduce
introduce key B' with alg2.

Note: Key A' and B' will not be trust anchors, don't use the SEP bit on
them.

> b) we must define that revoked key as an exception to RFC4035 2.2

That's one way to solve the issue, but that changes the protocol. We can
also describe how the rollover to a different algorithm should happen
that fits in the current specification.

> zone with new algorithm regardless of the hold-down timer.

The hold-down timer is meant for the resolver, the one who signs the
zone does not need to take the hold-down timer into account.

When you add a key C with a new algorithm, you already must have the
signatures for it in your zone (just like 4641bis already describes)

> outlined in draft-ietf-dnsop-rfc4641bis-04.txt

For clarification, if you do algorithm rollover.

> Is correct, but it still needs to follow the:

When rereading, it's actually not: The operator (I am guessing the zone
operator) should include the revoked 'A' in the RRset for at least the
Maximum Zone TTL, not the hold-down timer.

> If the 'C' has different algorithm then the step 2. and 4. are incorrect.

Yes, because for step 2 you need to add the signatures for C. The whole
scenario can imo actually not be narrowed down to the DNSKEY RRset, you
need to take the whole zone into account.

> you can update DS at parent.

Yes.

> the same time you add new keys.

Not at the same time, but that is also true for regular key rollover
(not switching algorithms). If 5011 is in place, algorithm rollover can
easily be extended with one extra stage, that is, before removing the
old key, revoke it. This requires a shadow key with the same algorithm
that signs the whole zone.

Best regards,

Matthijs