Subject: [dnsext] RFC 4035 and "caching" of "expired RRSIG's"

From: "Marc Lampo" <[email-masked]>
Date: Tue, 4 Jan 2011 10:51:50 +0100 (CET)

Hello group,
and my best whishes for a healthy and challenging 2011 !

Allow me to throw a question about "caching" of "expired RRSIG's".
In RFC4035, DNSSEC “protocol”, in section 4 : “Resolving”
4.5.  Response Caching

   A security-aware resolver SHOULD cache each response as a single
   atomic entry containing the entire answer, including the named RRset
   and any associated DNSSEC RRs.  The resolver SHOULD discard the
   entire atomic entry when any of the RRs contained in it expire.

In a preceding paragraph on “Recursive Name Servers” (3.2), it reads :
   The resolver side follows the usual rules for caching and negative
   caching that would apply to any security-aware resolver.

--> I interpret that the discarding of an entire atomic entry
    when (even at least) one RRSIG in it expire (even though others may be
still be valid)
    is a recommendation (only).

There are two aspects I feel might need some explicit clarification :
1) the "should", from 4.5, is to be interpreted as : "recommended"
    and "developer, know what you are doing when you do not implement
this"
    (free after rfc 2119)
   Consequently :
    some name server implementations/versions may chose to cache expired
RRSIG's

2) "*any* of the RRs ... expire"
   Fact is that multiple RRSIG's may be available,
    not all of which expired,
    and those that are still valid, may allow to perform full DNSSEC
validation.
   If taken literally, name servers that do implement discarding according
to 4.5 of RFC4035
    might not cache otherwise valid info (RRset + related RRSIG(set))
    as soon as one of the RRSIG's expires.
   As this might defeat the functioning of caching
    - there are name servers that almost continuously return an expired
RRSIG,
      In the presence of other, not expired, RRSIG(s) that do allow DNSSEC
validation -
   if at leased one received RRSIG is already expired upon reception.

   Consequently :
    Wouldn't it be wise to rephrase 4.5 of RFC4035 such that
     "DNSSEC validation becomes impossible"
    is meant ?

At this moment, as eu. top-level domain, we continue
to warn for RRSIG's that may expire while in some cache.
(because throwing them out of the cache is "recommended" only).
We feel this is in the interest of optimal DNSSEC operation.

Thanks for sharing your feedback.

Kind regards,

Marc Lampo
Security Officer
 
    EURid
    Woluwelaan 150    
    1831 Diegem - Belgium
    [email-masked]
    http://www.eurid.eu

Register your .eu domain name and win an iPod touch this X-Mas
http://www.winwith.eu
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Florian Weimer <[email-masked]>
Date: Tue, 04 Jan 2011 10:05:28 +0000

>      "DNSSEC validation becomes impossible"

Please clarify if you're concerned with TTLs or signature validity
periods.  (The quoted sections in the RFCs are strictly about TTLs,
and not about cryptographic constraints.)

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: "Marc Lampo" <[email-masked]>
Date: Tue, 4 Jan 2011 11:46:51 +0100 (CET)

Hello,

I understand what you mean, but the RFC uses the word "expire".
And that, by itself, can be interpreted in two ways :
1) the ttl counts down to 0
2) the present time is later then the "expiration date" of the (a ?) RRSIG
record

You indicate that this portion of the RFC handles TTL only,
 but the last paragraph of that section 4.5 states :
 "until the TTL or signatures ... expire"
 --> this leads to believe that it is not exclusively TTL only
That possible, dual, interpretation indicates the need for clarifation, I
would say.

And, if the original RFC meant the TTL only,
then the case of an RRSIG past expiration time (second interpretation
above)
 is not addressed at all, is it ?

Furthermore, since TTL of RRSIG RRset must be identical to the TTL of the
RRset it signs,
all records in the "atomic entry" should have the same TTL anyway.
Though I suppose that somehow, data might arrive/be refreshed at different
times,
yielding different TTL values in a validating name servers cache.

Kind regards,

Marc

---

From: Florian Weimer <[email-masked]>
Date: Tue, 04 Jan 2011 10:52:06 +0000

> That possible, dual, interpretation indicates the need for clarifation, I

The paragraph containing this statement sketches
NODATA/NXDOMAIN/wildcard synthesis and recommends against it.  For
that type of synthesis, you likely want to obey cryptographic
constraints because you only want to synthesize an answer which can be
proven cryptographically valid.  This is about pulling records from
thin air, and it is fundamentally different from regular caching
behavior.