Subject: Re: timers draft and parent DS records

From: Mike StJohns <[email-masked]>
Date: Sun, 30 Jul 2006 18:11:25 -0400

No, it shouldn't include that.  Section 4.3 describes deleting a 
trust point.  Once you've done that, you're no longer going to do 
anchor update for the trust points. So if you want to keep validating 
the zone, of course you need to update/create a DS record at the parent.

Section 5 describes what you do with an active trust point.  It's 
possible there is a superior DS and superior trust anchor, but if 
that's the case, why have that subordinate trust point?  Section 5 
describes the actions at the trust point to roll or update keys.  The 
actions your parent requires you to take may or may not include 
updating the DS record - and most of the time there won't actually be 
a DS record.

At 05:07 PM 7/28/2006, Robert Story wrote:
>Shouldn't the scenarios in section 5 include steps on updating parent
>DS records? The only discussion of updating parent DS records is in
>4.3. Trust Point Deletion. It seems to me that when you roll a SEP key,
>you'd want to update the parent DS so resolvers which have a superior
>trust point configured would continue to validate the zone data.
>
>--
>Robert Story
>SPARTA
>

--
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: Robert Story <[email-masked]>
Date: Sun, 30 Jul 2006 19:03:42 -0400

On Sun, 30 Jul 2006 18:11:25 -0400 Mike wrote:
MS> Section 5 describes what you do with an active trust point.  It's 
MS> possible there is a superior DS and superior trust anchor, but if 
MS> that's the case, why have that subordinate trust point?

Maybe because the superior trust point is new, and not everybody has
updated their resolver configuration.

I've re-read 4.3 a few more times, and have a question. If a zone
revokes all its trust anchors, and there is a superior trust anchor
(which is not configured at a resolver), is the resolver supposed to
save (and trust) the superior trust point?

MS>  Section 5 
MS> describes the actions at the trust point to roll or update keys.  The 
MS> actions your parent requires you to take may or may not include 
MS> updating the DS record - and most of the time there won't actually be 
MS> a DS record.

That will probably be true, initially. But as deployment grows, so will
the number of trust points higher in the DNS tree. As that's happening,
it will take time for resolver configurations to get updated. Unless
4.3 does mean there is auto-trust of superior trust points (which I
don't particularly think is a good idea), care needs to be taken during
the transition period.

Also, I'm sure some domain owner's will continue to publish their own
trust points even if there is a superior trust point. Just because they
will be in the minority doesn't mean we should ignore them. Unless we
want to rename the document "Automated Updates of DNSSEC Trust Anchors
For Zones With No Available Superior Trust Points".

-- 
Robert Story
SPARTA

---

From: Mike StJohns <[email-masked]>
Date: Sun, 30 Jul 2006 19:29:09 -0400

>updated their resolver configuration.

This is not in scope for this document.  4.3 talks about deleting a 
trust point and the ramifications.  Section 5 talks about the normal 
operations for a trust point - regardless of whether there are 
superior trust anchors.  Refer to the normal DNSSEC documents for how 
to deal with DS records etc.  I don't need to and will not repeat DS 
management discussions in this ID.

>save (and trust) the superior trust point?

No and HUH? This is a meaningless question.

If a resolver deletes all the trust anchors associated with a zone 
and there are no trusted superiors, the zone goes to the insecure 
state - it may be signed, but there's no way for the resolver to know 
whether or not the zone should be signed (the same state as almost 
all of the DNS tree today).  The only way a trust point gets created 
is manually  (by setting a trust anchor for a specific location) or 
some other method (not defined here or as far as I can tell elsewhere).

The text that covers the above is: "
If there are no superior trust points, data at and below
    the deleted trust point are considered insecure.  If there ARE
    superior trust points, data at and below the deleted trust point are
evaluated with respect to the superior trust point."

The trust anchor runs from parent to child, not vice versa.  Trusting 
a child does not in any way allow you to trust the parent.
>don't particularly think is a good idea), care needs to be taken during

Umm.. how in any reading of the text could you get that 4.3 implies 
that you auto-trust a superior?  I think you're way off in the weeds here.

>For Zones With No Available Superior Trust Points".

You're setting up strawmen and trying to knock them down.  I'm not 
sure why you're doing that.

There is nothing in 4.3 (or for that matter, anywhere else in the 
document) that prohibits trust points superior or subordinate to 
other trust points.  4.3 simply describes a method to automatically 
inform resolvers that you want them all to delete a configured trust point.

---

From: Robert Story <[email-masked]>
Date: Mon, 31 Jul 2006 10:59:42 -0400

On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote:
MS> Umm.. how in any reading of the text could you get that 4.3 implies 
MS> that you auto-trust a superior?  I think you're way off in the weeds here.

I was indeed wandering in the weeds, and my question was just to make
sure. As to how I got there: I do not see any such implication, but
after re-reading it several times, I noticed that while later
paragraphs talked about 'configured' trust points, the first paragraph
only says "If there ARE superior trust points". I suggest adding the word configured in the first paragraph as well.

Now, on to my main point, which got lost in the confusion. Deleting the
reference to 4.3 from my original message:

At 05:07 PM 7/28/2006, Robert Story wrote:
>DS records? [...] It seems to me that when you roll a SEP key,

And the eventual response:

On Sun, 30 Jul 2006 19:29:09 -0400 Mike wrote:
MS> This is not in scope for this document. [...] Section 5 talks about the
MS> normal operations for a trust point - regardless of whether there are 
MS> superior trust anchors.  Refer to the normal DNSSEC documents for how 
MS> to deal with DS records etc.  I don't need to and will not repeat DS 
MS> management discussions in this ID.

With all due respect, I disagree. If you don't want to added anything
to the individual scenarios, I think there should at least be a few
words about it in the introduction of section 5 (suggested text
included at the bottom of this message).

While this document is primarily about resolvers, it also specifies
procedure for zone administrators (sections 5 and part of 4.3). Zone
administrators must add/revoke/remove keys in the proscribed manner for
resolvers to automatically update their trust anchors. Given that we
are describing the rollover procedure for zone administrators, I think
we need to at least mention the potential pitfall when the parent zone
is signed.

As requested, I'm including some suggested text, which I think should be
added after the 2nd paragraph of section 5:

   N.B. The steps outlined below assume an unsigned parent zone.
   When keys are added, revoked or removed from a zone with a signed
   parent, the parent zone should be notified so that DS record(s) can
   be updated appropriately. Failure to do so will prevent resolvers
   which only have a superior trust point configured from securely
   resolving the subordinate zone.

-- 
Robert Story
SPARTA

---

From: Mike StJohns <[email-masked]>
Date: Mon, 31 Jul 2006 21:22:50 -0400

At 10:59 AM 7/31/2006, Robert Story wrote:
>only says "If there ARE superior trust points". I suggest adding the 
>word configured in the first paragraph as well.

OK - that's fine.

>procedure for zone administrators (sections 5 and part of 4.3).

Actually, it doesn't.  Section 5 and much of section 4.3 are 
informative, not normative.  The IETF is not allowed to include 
people as protocol elements as much as we'd like to.

One of the reasons for not adding your proposed language is that DS 
updates are covered in part in section 2.4 of RFC 4035 which says in part: "
    Construction of a DS RR requires knowledge of the corresponding
    DNSKEY RR in the child zone, which implies communication between the
    child and parent zones.  This communication is an operational matter
    not covered by this document."

If that document declines to discuss DS operations, it seems clear 
this document should not (and indeed must not) create a normative 
requirement on DNSSEC for things outside its purview (e.g. the DS 
record).    If this document becomes a standards track RFC, some of 
what your saying MAY be appropriate for whatever later revisions 
occur to 
<https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=11111>draft-ietf-dnsop-dnssec-operational-practices-08 
or its successor(s).

>Zone