Subject: Q-29: Resolver Handling of expired RRSIGs

From: "Scott Rose" <[email-masked]>
Date: Tue, 3 Feb 2004 12:47:01 -0500

Q-29  Resolver handling of expired RRSIGs

From an earlier thread and individual comments:

What, if any, should be the default resolver behavior
when expired RRSIGs are contained in a response?  For example,
The one or more RRSIGs covering a RRset in the answer section
has  an expiration date in the past.

Currently, the text in the Records and Protocol document
state that they MUST be rejected (they are to be considered
"bogus", using the newly defined terminology).  Some have
suggested that is too harsh, and the default should be something
similar to the following:

"SHOULD be rejected, but MAY use RRSIGs if other security
checks were successful, depending on local policy".

That way, a resolver may be able to pass on success, and the
data could be marked "unsecure" and passed back to a security
aware stub resolver, or passed up to the application.  However,
if the application or stub resolvers are not security aware, this
could lead to a vulnerability.

Is there consensus to relax the "MUST reject expired RRSIGs" and
make it less restrictive?  Please suggest text if the above is
not sufficient.

This formal question is mainly for closure on a discussion thread that has
died down.

--
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: bill <[email-masked]>
Date: Tue, 3 Feb 2004 10:16:51 -0800 (PST)

> checks were successful, depending on local policy".

	better language, imho.

> make it less restrictive?  Please suggest text if the above is

--bill