At 15:05 22/04/2009, Paul Wouters wrote:
On Wed, 22 Apr 2009, Peter Koch wrote:
Please review the draft and send comments and/or statements of support or
non-support to the WG mailing list.
It seems a comma is missing between Scott's name and mine.
Fixed,
One issue came up recently with the dnssec-conf package related
to Section 4, Trusted update mechanism..
If an OS ships with preloaded trust anchors, and the medium is
used over a year after it was created, eg an old CD/DVD copy, it
might cause DNS to complete fail due to loading rolled over
trust anchors. This DNS failure will prevent it from obtaining
an updated trust anchor update if those reside within one of these
zones.
The question is what to do, or what to recommend. For Fedora/EPEL,
I'm leaning towards automatically disabling all trust anchors (which
includes DLV) if the package build date is older then 9 months. At
the same time, we will commit to releasing at least a new package
every 6 months, even if no changes were made and we are just bumping
the release number. Upon package update, the resolver is restarted
and the same check that disabled the trust anchors before will now
accept the new package date, and enable trust anchors again.
It might make sense to add a warning about this issue in the RFC?
IMHO the OS update package mechanism should be a signed update that
lives longer than any DNS TA distribution file.
I see two different issues here:
a Software Update with TA's should only be valid for a certain
time window
ability of a system that is loaded/restarted long time after
it is "configured" to perform DNSSEC verifications.
On the first one: send text
On the second one: we need a different mechanism see Wouter's draft
on trust history.
If we had Trust history and a history interpreter then the age of
the distribution would not matter that much.
Not sure what to do here
Olafur
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
