Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

[Nicholas Weaver <[e-mail]>]

On Feb 21, 2014, at 7:59 AM, Paul Wouters <[e-mail]> wrote:

> On Fri, 21 Feb 2014, Nicholas Weaver wrote:
> 
>> The only disadvantage is that on the server side you need to get this data fairly frequently, since the timeout may be fast (first expiring RRSIG on the chain of validation from . to the DANE record), which means the very rarely updating certificate store model common to web servers isn't appropriate, but that's no real-big-deal.
> 
> huh? If I put a 9999999 rrsig timeout on my TLSA signature, once you
> fetched it, it is pretty irrelevant that somewhere upstream an rrsig
> expired.
> 
> Are you suggesting resolvers should throw away chains of dns from the
> cache once a single rrsig expires?

F-yeah.  An RRSIG's validity interval should not extend beyond the validity interval of all RRSIGs needed to validate this RRSIG.  DNSSEC does not have a revocation mechanism, but in lieu of a revocation mechanism you have the much more limited validity of RRSIGs, and if the upstream authority says your DS record expires in an hour, why should you be able to override that policy?



But even if thats not the case, an non-DNS server which provides the data on demand, namely a full validation chain, needs to treat things this way, as it would not be able to provide a valid-at-the-time RRSIG: yeah, your 9999999 RRSIG might still be valid, but the captured RRSIG for the DS from the authority server also needs to be valid when it is presented to the client.


So lets take a real world case, www.isc.org:

Record		Expires
DS org		2014-02-28-000000
DNSKEY org	2014-03-10-155510
DS isc.org	2014-03-10-155510
DNSKEY isc.org	2014-03-19-230128
A www.isc.org	2014-03-19-233241

A non-DNS server which is providing a DNSSEC validation chain for www.isc.org needs to be aware of all these expiration times: there are at least 3 (and possibly 4) separate expiration intervals, all with different phase to boot.

And I'd expect the expiration times for DNSSEC records to go down, rather than up, as people realize that online signing offers some significant advantages operationally (dynamic NSEC3 lies, quick reacting DNS load balancing, etc) and the cost of online signing may have been expensive 10 years ago but is nearly free today.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[e-mail]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc