Subject: WGLC on rollover-requirements and trustudpate-timers

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 25 Sep 2006 22:00:12 +0200

Dear Colleagues,

This message starts the working group last call for two documents

           draft-ietf-dnsext-rollover-requirements-03
      Requirements related to DNSSEC Trust Anchor Rollover

             draft-ietf-dnsext-trustupdate-timers-04
           Automated Updates of DNSSEC Trust Anchors

The documents and their history can be found at:

http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-rollover-requirements/
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-timers/

It is the intention to publish the "requirements" draft as an
informational RFC and to publish "timers" on standards track.

As previously, for each document we would like to see at least 5 people
going on record for having thoroughly reviewed it.

We would appreciate assessments on how well 'timers' fits  
'requirements' [*]

Last call terminates October 11, 2006.

Your chairs,

Olaf and Olafur.

[*] Even though there is no reference from the timers draft to the
requirements draft we learned by experience with that the IESG is
interested and aware of requirement documents and takes interest
reviewing them both.

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: "dr. W.C.A. Wijngaards" <[email-masked]>
Date: Wed, 27 Sep 2006 14:36:22 +0200

Hi,

Some comments on the timers draft-04, which is in WGLC.

In Section 2.3 Remove Hold-down
This contradicts other sections, I think it is an error.
The last sentence says the resolvers when they see a DNSKEY RRSet
without that *new* key, wait for remove hold-down and then discard it.
But this is not true. new keys (addpend state) are immediately discarded
by the resolver when absent from the RRset. It is true for valid keys
when the revocation bit is set, but not true for missing keys that stay
around forever. So, 2.3 needs some rewording to make sense. Proposal;
	2.3. Remove Hold-down
	A new key which has been seen by the resolver, but hasn't
	reached it's add hold-down time, MAY be removed from the
	DNSKEY RRSet by the zone owner. If the resolver sees a
	validated DNSKEY RRSet without this new key, it will discard
	any information about the key.
	If a validated DNSKEY RRSet contains a key with revoked bit
	on, and during the remove hold-down period all DNSKEY RRSets
	that validate contain the key with revoked bit on, then
	after the remove hold-down period has elapsed
	the resolver can discard any information about the key.
	If a validated DNSKEY RRSet does not contain some keys,
	these keys are said to be missing, and will only be discarded
	after the expiration time from the RRSIG seen last over
	the key has passed.
Well this is a bit wordy, but I think it works.

In section 2.4 Active Refresh.
The last sentence talks about the expiration interval. You mean the
expiration interval from the DNSKEY RR, and not the one from the zone
SOA. Please state as 'RRSIG expiration interval' once.

In section 4.1 Events.
For RemTime: please change 'key has been missing from the trust point'
to 'key has been present with revoked bit or missing from the trust
point'. (I think this is a minor overlook when you added in the
revocation bit).

If a query fails, 10% of TTL could be less than an hour, then how often
to retry?

[answer to discussion item there]
For the 'Missing' state, I would like that to time out, and move to
Removed, even if that timer is longer than RemTime. This will make even
for badly managed zones that missing keys won't clog up the validator.
The security reason is that a missing key may be cracked after some time
and be made 'Valid' again by presence. And if missing keys stay around
forever, then crypto will advance to the point where it is cracked. Of
course, the admin of the zone should manage his key rollover more
carefully too.
So when the key expires (from the key expiry time in the RRSIG RR) a
Missing key can go to 'Removed'.

On section 5. Trust Point Deletion. I have a lot to say.
I'll start with saying I completely agree with the first paragraph.

The second paragraph says local configuration MAY delete subordinate
trust anchors. I would like to keep this second paragraph but also add a
third that says local configuration MAY add(or keep) subordinate trust
anchors.

When subordinate trust anchors are deleted, you become more dependent on
the superior trust point. And if the operators of the trust point (or
software) fail and the superior trust point goes bad or the chain of
trust to the subordinate trust point is broken, then the subordinate
zone becomes inaccessible bogus. So to make children more independent of
their parent zones, and parent zone maintenance, I would like to allow
local configuration to add new trust points below existing trust points
when the chain of trust is validated, according to local configuration,
and up to some maximum number per superior trust point.

The idea is that local configuration could help so that if the .foo
operators bungle up, then if a user visited bank.foo recently, he can
continue to do business.

Sample text:
Also, subordinate trust points MAY be added, when the chain of trust to
a superior trust point is validated, according to local configuration
options and up to some maximum number of subordinate trust points. The
trust point is added by storing the SEP keys that validated in 'Valid'
state. This keeps a cache of (recently used) subordinate trust points in
case a superior trust point fails or disappears.

In section 6.2. Deleting a Trust Anchor
change 'revolcation' to 'revocation'.
Notice that the operator SHOULD revoke by setting revocation bit. This
is more reason to treat missing keys that expire as Removed.

Best regards,
   Wouter

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Scott Rose <[email-masked]>
Date: Wed, 27 Sep 2006 13:37:41 -0400

> case a superior trust point fails or disappears.

I understand the text, but I don't know if it is totally up to the 
validator.

This would only apply if the child sub-zone also maintains it's secure 
entry point key like a trust anchor.  That might not always be the case. 
  Some sub-zones may choose to rely on their parent to be the trust anchor.

Scott

---

From: Mike StJohns <[email-masked]>
Date: Thu, 28 Sep 2006 13:50:33 -0400

Thanks for the comments, but I think they're mostly 
not-applicable.  See my comments in line.  Also, I think you were 
looking at the -03 or -02 document rather than the -04.  There are no 
pending discussion items.

At 08:36 AM 9/27/2006, dr. W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi,
>

Unfortunately, you're restatement is incorrect.  Section 2.3 applies 
to what the zone owner is doing with the key.  If the key hasn't been 
in the DNSKEY RRSet for the add hold down time, the zone owner may 
remove the key and need not actually revoke it as no compliant 
resolver would have added it as a trust anchor.  The action on the 
part of the resolver for the KeyRem event is to move the key back to 
the Start state - not necessarily forget about it.  After the add 
hold down time the resolver can remove any information about the key 
(to be fair, it can remove the information about any key in the start 
state, but it made sense to state this case explicitly and was done 
so due to an early comment).

I am going to lower case the MAY as this is an action by a person 
rather than a protocol element and isn't subject to standardization.

Perhaps a better approach would be to simply delete this paragraph 
and the related 2.5.2 paragraph - I don't know that the remove hold 
down is all that useful in the current instantiation.   OTOH it does 
no harm to leave it.

I'm going to leave this pending operational experience, but will 
probably recommend removal if/when we go to draft standard.

>SOA. Please state as 'RRSIG expiration interval' once.

Read the sentence in the paragraph before it which states "
The expiration interval
    is the amount of time from when the RRSIG was last retrieved until
    the expiration time in the RRSIG."

No change.

>point'. (I think this is a minor overlook when you added in the

Not an overlook.  The trust point state contains the state of a) all 
keys in the most recent DNSKEY RRSet and b) revoked keys that haven't 
yet reached the remove time.  I wanted to leave keys that were still 
being included in the DNSKEY RRSet simply to make state management 
easier.  No change.

>If a query fails, 10% of TTL could be less than an hour, then how often

1 hour.  I'll twiddle this once again.

>Missing key can go to 'Removed'.

No.  I'm not sure which version of the document you're looking at, 
but that discussion item was resolved several months ago.  Keys won't 
be revoked unless they are explicitly revoked.

The following is all out of scope for a WGLC - if you wanted a 
mechanism for adding subordinate trust anchors, you should have 
spoken up 2 years ago. Its also not in the requirements document.

>change 'revolcation' to 'revocation'.

OK.

>is more reason to treat missing keys that expire as Removed.

No.  This is a settled point and won't be revisited in the 
WGLC.  Keys are revoked and removed ONLY with the revoke bit - go 
back and review the last 6 months of discuss to understand why.

>Best regards,
>    Wouter
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.5 (GNU/Linux)
>Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
>iD8DBQFFGnBFkDLqNwOhpPgRAs9YAJ4iRhTfFMd+MRg4R+AfEV3EM/TdrgCgh4Me
>J06na6dHPrPZRqHP7cJypD8=
>=zGeK
>-----END PGP SIGNATURE-----
>
>--

---

From: Mike StJohns <[email-masked]>
Date: Thu, 28 Sep 2006 14:16:02 -0400

Do a search on "3 Comments on timers-03"  in the namedroppers archive 
(around 27 July) to see some of the discussion on "revoke if missing" 
and why it's a bad idea.

At 01:50 PM 9/28/2006, Mike StJohns wrote:
>looking at the -03 or -02 document rather than the -04.  There are 
>no pending discussion items.
>
>to what the zone owner is doing with the key.  If the key hasn't 
>been in the DNSKEY RRSet for the add hold down time, the zone owner 
>may remove the key and need not actually revoke it as no compliant 
>(to be fair, it can remove the information about any key in the 
>start state, but it made sense to state this case explicitly and was 
>done so due to an early comment).
>
>keys in the most recent DNSKEY RRSet and b) revoked keys that 
>haven't yet reached the remove time.  I wanted to leave keys that 
>were still being included in the DNSKEY RRSet simply to make state 
>management easier.  No change.
>
>
>but that discussion item was resolved several months ago.  Keys 
>won't be revoked unless they are explicitly revoked.
>
>

---

From: "dr. W.C.A. Wijngaards" <[email-masked]>
Date: Thu, 28 Sep 2006 22:13:50 +0200

Hi Mike,

Thanks for the response,

> (around 27 July) to see some of the discussion on "revoke if missing"

Yeah I saw, reread it, and no problem with that. A missing key should be
retained because that may be a fluke by the operator. But the missing
keys should be gone after some amount of time (even if its a year). More
than enough for an operator to fix any mistakes.

>> Thanks for the comments, but I think they're mostly not-applicable. 
>> See my comments in line.  Also, I think you were looking at the -03 or
>> -02 document rather than the -04.  There are no pending discussion items.

No I was really looking at -04. (with section5 trust point deletion
section). I double checked just now.

>>> the Start state - not necessarily forget about it.  After the add hold
>>> down time the resolver can remove any information about the key (to be
>>> fair, it can remove the information about any key in the start state,
>>> but it made sense to state this case explicitly and was done so due to
>>> an early comment).

What I did not understand about 2.3 is that this 'key which has been
seen by resolver', and the whole section, is about keys in the Start
state. I thought you meant another state, or even to describe all
states. It makes sense when you realise it is about the Start state.
I am sorry there was some confusion here on my part.

>>> rather than a protocol element and isn't subject to standardization.

no MAY because it is a valid protocol action towards the validators;
surely key-management will see automation as well.

>>> Perhaps a better approach would be to simply delete this paragraph and
>>> the related 2.5.2 paragraph - I don't know that the remove hold down
>>> is all that useful in the current instantiation.   OTOH it does no
>>> harm to leave it.

>>> probably recommend removal if/when we go to draft standard.

I think its okay now.

>>>    the expiration time in the RRSIG."

Yes.

>>> being included in the DNSKEY RRSet simply to make state management

Ahh okay, so deletion is slower than I first understood. First the phase
of revocation in the keyset (which can take any amount of time). Then
the phase not-in-the-keyset (but resolver is waiting for RemTime to
expire).

>>> 1 hour.  I'll twiddle this once again.

thanks.

>>> No.  I'm not sure which version of the document you're looking at, but
>>> that discussion item was resolved several months ago.  Keys won't be
>>> revoked unless they are explicitly revoked.
>>>

so on
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-trustupdate-timers/draft-ietf-dnsext-trustupdate-timers-04.txt
page 9 at the top of the page, under the Missing: heading in Section 4.2
There the discussion item is mentioned.

So I support the revoke bit - I voted in its favor before.
Missing keys must not be removed quickly. I agree with that too.
Removing missing keys after a very long time is acceptable I think.

>>> mechanism for adding subordinate trust anchors, you should have spoken
>>> up 2 years ago. Its also not in the requirements document.

Ahh I see. It increases failure resistance. This is why I brought it up.
Because failure gives bogus this is a strong motive.

>>> No.  This is a settled point and won't be revisited in the WGLC.  Keys
>>> are revoked and removed ONLY with the revoke bit - go back and review
>>> the last 6 months of discuss to understand why.

Yes I saw those, and I agree revoked bit should be used. However, a
missing key should not be lingering around forever (and ever and ever).
It eats memory on the validator.

Just to say, that I support the document going forward (I said so
before, I only make these comments to improve text).

Best regards,
   Wouter
- --
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: < http://ops.ietf.org/lists/namedroppers/>

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Fri, 29 Sep 2006 17:07:45 +0200

On 29Sep 2006, at 4:51 PM, Scott Rose wrote:

>
> Hope this helps/sparks discussion

Or at least reminds other folk to do the same...

--Olaf

---

From: Scott Rose <[email-masked]>
Date: Fri, 29 Sep 2006 10:51:15 -0400

>           Automated Updates of DNSSEC Trust Anchors

I support advancing both documents.  From my POV:

Requirement [does timers-update meet requirement?]

1 scalability [yes]

2 No intellectual property encumbrance [yes?] *not 100% sure, could be 	
					       surprised again.

3 general applicability [yes, possible]

4 support private networks [yes]

5 Detection of stale trust anchors [possible, up to zone admin as to how
   many revoked keys are in the DNSKEY RRset]

6  manual operations permitted [yes, but require admin to time events]

7 planned and unplanned rollovers [yes]

8 timeliness [yes, assuming resolvers query for the trust anchor's
   DNSKEY RRset]

9 high availability [yes, as long as the resolver can get to one of the
   zone servers]

10 New RR types required [No, but requires new flag in DNSKEY RR flags
    field, also requires additional logic for using revoked DNSKEYs
    during validation]

11 Support for trust anchor maintence ops [yes]

12 Recovery from compromise [yes]

13 non-degrading Trust [yes]