Subject: New Version Notification for draft-wijngaards-dnsext-trust-history-01

From: Wouter Wijngaards <[email-masked]>
Date: Thu, 18 Oct 2007 15:49:29 +0200

Hi dnsext,

Some time ago I wrote this draft about DNSSEC trust anchor rollover. I
have updated it now with some corrections and an example. I hope this
makes it easier to read.

I would like to ask if the dnsext group wants to adopt this work. The
method described (IMHO) fills gaps in the currently available
trust-anchor-update mechanisms, that previous drafts did not address.

The main thrust of the draft is this:
When a resolver has been offline for a long time (for a variety of
reasons), it cannot keep up with regular updates. Therefore, a history
of key states is kept, that can be used to bring the resolver back online.

It can be deployed incrementally, can coexist with other update
mechanisms (such as -timers and software update), has algorithm
flexibility, and handles key revocation. AFAIK there are no patent
issues regarding this work. I believe it addresses all of RFC 4986
concerns, with initial trust possible, and a chance of being able to
rollover for longer-offline cases. It can also provide multiple key
compromise protection (like the N out of N-draft did).

Best regards,
   Wouter

Subject: New Version Notification for draft-wijngaards-dnsext-trust-history-01
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Date: Fri, 12 Oct 2007 04:39:31 -0400

A new version of I-D, draft-wijngaards-dnsext-trust-history-01.txt has been successfuly submitted by Wouter Wijngaards and posted to the IETF repository.

Filename:	 draft-wijngaards-dnsext-trust-history
Revision:	 01
Title:		 DNSSEC Trust Anchor History Service
Creation_date:	 2007-10-10
WG ID:		 Independent Submission
Number_of_pages: 16

Abstract:
When DNS validators have trusted keys, but have been offline for a
longer period, key rollover will fail and they are stuck with stale
trust anchors.  History service allows validators to query for older
DNSKEY RRsets and pick up the rollover trail where they left off.
The service can be made to withstand multiple key compromises and
large-scale spoofing.Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].

The IETF Secretariat.

---

From: Thierry Moreau <[email-masked]>
Date: Thu, 18 Oct 2007 12:00:11 -0400

Dear all:

This work seems to fulfill two goals:

	A specification that allows a (island of trust) zone manager to publish 
history of RFC5011 (timers-based rollover mechanism) events, intended 
only for resolvers that were off-line for a too long duration, and 
effective only when the RFC5011 events were not triggered by a security 
breach.

	With the proposed "priming keys" mechanism, a substitute for RFC5011 
rollover mechanism. OK, the original intent might have been to fix a 
limitation of the solution for first goal, but the result is indeed an 
alternate trust anchor rollover mechanism. I don't know if this "priming 
key" mechanism is detailed enough, e.g. the rollover of priming keys is 
kind of vaguely described as "only ... when this becomes necessary."

I doubt the dnsext wg would pick up either goal as a priority, but we 
will see.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

--
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/>