Also see thread starting at:
http://darkwing.uoregon.edu/~llynch/dnsop/msg03465.html
This combines what I first marked as two topics.
In the discussion between Ed and Olaf the first was the last to respond in the
thread below:
> >>
> >> #4.4.4 DS Signature Validity Period
> >> #
> >> # Since the DS can be replayed as long as it has a valid signature, a
> >> # short signature validity period over the DS minimizes the time a
> >> # child is vulnerable in the case of a compromise of the child's
> >> # KSK(s). A signature validity period that is too short introduces the
> >> # possibility that a zone is marked Bogus in case of a configuration
> >> # error in the signer. There may not be enough time to fix the
> >> # problems before signatures expire. Something as mundane as operator
> >> # unavailability during weekends shows the need for DS signature
> >> # validity periods longer than 2 days. We recommend the minimum for a
> >> # DS signature validity period of a few days.
> >
> >>
> >> Weeks. For a large zone, days are not enough.
> >>
> >> It's not the signing that's a problem, it the management of the registry
> >> that is.
> >
> >If the signing is not a problem than I do not understand why the
> >management of the registry is a problem; the DS RRs that are published
> >by the parent are not subject to change.
>
> It's been long said that the signing of DNSSEC is the easiest part of
> the problem - ever since the first complaints that the early signers
> took a lot of time.
>
> The problem is that, in operations, things go wrong. Hardware fails,
> demand fluctuates, the world is not inherently cyclical no matter how
> hard the ops staff tries to make it. Because of this, you want to
> set up events that are easily identifiable (so you can tell if it
> happened or not) and you want to leave spare time for catch up. If
> ths signing process doesn't fire on Tuesday night because of an
> upgrade to the air conditioning units, you have to allow for it to
> happen a week later because maybe there is other work due on
> Wednesdays.
>
> >Or is "the management of the registry" not a piece of software but
> >pieces of bio-ware that sets the minimal values?
>
> A registry is not a software chunk, it's a conglomeration of
> subsystems - including things like billing that are usually
> forgotten, layered on top of utilities that have a mind of their own.
>
> We've often said that DNSSEC complicates the delegations in DNS.
> Delegations are hard enough to manage today. For this section, what
> I ask is that we do not appear too optimistic in our timing
> recommendations.
>
> >----------------------------------------------------------------------
> >> # The maximum signature validity period of the DS record depends on how
> >> # long child zones are willing to be vulnerable after a key compromise.
> >> # Other considerations, such as how often the zone is (re)signed can
> >> # also be taken into account.
> >> #
> >> # We consider a signature validity period of around one week to be a
> >> # good compromise between the operational constraints of the parent and
> >> # minimizing damage for the child.
> >>
> >> One week is not realistic, one month is what to prepare for. IMHO,
> >> putting any timescale in this document might create unrealistic
> >> expectations unless the timescale is a necessary piece of the
> >> protocol.
> >
> >Hmmm, the document doesn;t force you to choose this particular compromise.
> >
> >I do think that putting timescales in is something that the "DNSOP"
> >group can do even though the timing is not piece of the protocol. In
> >the document we argue the tradeoff and argue that the timescale is a
> >compromise.
> >
> >I do get your point though, you would not like to see this document
> >being stuffed in your face if you do not meet these
> >recommendations. Maybe we can address this in the introduction of the
> >text by adding a line to the first paragraph of the Introduction:
> >
> >
> > During workshops and early operational deployment tests, operators
> > and system administrators gained experience about operating the DNS
> > with security extensions (DNSSEC). This document translates these
> > experiences into a set of practices for zone administrators. At the
> > time of writing, there exists very little experience with DNSSEC in
> > production environments; this document should therefore explicitly
> >+ not be seen as representing 'Best Current Practices'. The intention of
> >+ this document is to provide guidance, it should not be used to argue
> >+ that operators violate best practices when they choose not to follow
> >+ recommendations herein.
>
> On the one hand, I see a few places where IETF documents have been
> taken too seriously. On the other hand, I have seen a few places
> where a lack of a clear statement has led to a morass of problems.
>
> For example, statements made about IPv6 allocations that appeared in
> IETF documents 5 years ago still rule conversations in the RIRs.
> Alone this is not bad, but there are some who have taken time to
> acknowledge that the IETF of 5 years ago has significantly less
> experience than the operator community of today. (To emphasize my
> point without engendering a flamefest - the IETF of 5 years ago has
> much less operational experience than the IETF of today too, but I
> didn't mean to compare that.) The documentation of years ago is
> still pertinent, but some have refused to question it.
>
> I also see where not saying enough leads to problems. Service level
> agreements are needed to judge the expectations and performance on
> either side of a contractural agreement. When there are many
> contracts for similar service, there is a natural tendency to compare
> the performers. This can't be fairly done if the service levels are
> measured on an ad hoc basis - which is what happens in a vacuum of a
> standard recommendation.
>
> This is kind of long-winded in saying that I am concerned that the
> words above may not be taken seriously but I think softening the
> document in other areas is a mistake.
>
> >> # In addition to the signature validity period, which sets a lower
> >> # bound on the amount of times the zone owner will need to sign the
> >> # zone data and which sets an upper bound to the time a child is
> >> # vulnerable after key compromise, there is the TTL value on the DS
> >> # RRs. By lowering the TTL, the authoritative servers will see more
> >> # queries, on the other hand a low TTL increases the speed with which
> >> # new DS RRs propagate through the DNS. As argued in Section 4.1.1,
> >> # the TTL should be a fraction of the signature validity period.
> >>
> >> A lower TTL doesn't really increase "the speed with which new DS RRs
> >> propagate through the DNS." What is true is that it "lowers the
> >> persistence
> >> of DS RRSets in caches, forcing more queries to the authoritative
> >> servers."
> >
> >
> >How about:
> >
> > By lowering the TTL, the authoritative servers will see more
> > queries, on the other hand a low TTL lowers the persistence of old
> > DS RRSets in caches thereby increases the speed with which new DS
> > RRs propagate through the DNS.
>
> Lowering the TTL, lowering the REFRESH, and flattening the zone transfer tree.
>
> I would reword as this:
>
> Shortening the TTL means that the authoritative servers will see more
> queries. But on the other hand, a short TTL lowers the persistence of
> DS RRSets in caches thereby increases the rapidity with which updated DS
> RRSets propagate through the DNS.
>
So as a result of the above I propose not to "weaken" the introduction
by adding the text proposed above but have rewritten the recomendation:
4.4.4 DS Signature Validity Period
Since the DS can be replayed as long as it has a valid signature, a
short signature validity period over the DS minimizes the time a
child is vulnerable in the case of a compromise of the child's
KSK(s). A signature validity period that is too short introduces the
possibility that a zone is marked Bogus in case of a configuration
error in the signer. There may not be enough time to fix the
problems before signatures expire. Something as mundane as operator
unavailability during weekends shows the need for DS signature
validity periods longer than 2 days.
The maximum signature validity period of the DS record depends on how
long child zones are willing to be vulnerable after a key compromise.
On the other hand shortening DS signature validity interval increases
the operational risk for the parent. Therefore the parent may have policy
to use signature validity interval that are considerably longer than
the child would hope for.
A compromise between the operational constraints of the parent and
minimizing damage for the child may result in signature validity
period somewhere between the order of a week to order of months.
In addition to the signature validity period, which sets a lower
bound on the amount of times the zone owner will need to sign the
zone data and which sets an upper bound to the time a child is
vulnerable after key compromise, there is the TTL value on the DS
RRs. Shortening the TTL means that the authoritative servers will see more
queries. But on the other hand, a short TTL lowers the persistence of
DS RRSets in caches thereby increases the rapidity with which updated DS
RRSets propagate through the DNS.
--Olaf
---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC
---------------------------------| JID: olaf at jabber.secret-wg.org
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
