Re: [DNSOP] watching for signature expiration in zones you don't sign

[Edward Lewis <[e-mail]>]

Time is a pain in the neck.  Conversations over the meaning of timers 
and time fields have gone on for a long time.

Keep in mind the difference between absolute (or wall clock) time and 
relative time.  The latter is even stickier because the time may be 
relative to an event that is local and not even zone-wide.

What timers are used to do is to govern different, often orthogonal 
operations and events in the DNS system.  The TTL is there to govern 
freshness of cached records in a server.  The SOA timers are there to 
govern the freshness of a copy of a zone in a slave server. 
Authority (only) servers have no notion of time and we've made 
strides to keep it that way.  (At least in the protocol.)

DNSSEC came along with absolute time.  That is a novelty of the 
extensions.  The time was used to do two things - protect the 
cryptographic relevance of the signature and to limit the impact of 
replay attempts.

Along the way many have confused the meaning of the timers.  TTL 
trimming to the signature expiration is one abuse, arguably one that 
makes sense.  In the purity of the protocol it doesn't but given 
operational realities that there may be a forced downstream validator 
that needs this trimming to be done.

At 11:43 -0400 6/2/11, Olafur Gudmundsson wrote:

>Strictly speaking from a protocol point of view any signature that expires
>before (zone expiry + RR TTL) is a potential validation failure.

The signature expiration is in absolute time.  Zone expiry (and 
refresh/retry) is a relative time.  TTL is also a relative time.

Whether the signature expiration time will arrive before the 
expiration of the zone or the cache entry is a question relative to 
the time you ask.

The base time for, say zone expiry, is relative to the slave server 
and is not revealed via the protocol.  And it is server specific, not 
zone specific!

So - there's no way to determine if "any signature ... expires 
before" zone expiry or RR TTL.

>Any Signature that expires before corresponding TTL is a likely validation
>failure if there is a non DNSSEC validating cache in the path.

What do you mean by "in the path"?

There's no protocol error in shipping an expired signature.  It's up 
to the receiver to decide if that matters.  We stopped requiring zone 
loading to check signatures like 10 years ago.

>Any Signature that has expired is bad.

http://tools.ietf.org/html/draft-wijngaards-dnsop-trust-history-02 
says differently.

>The issue is that many zone owners do not

>a) Do not know how long it takes to distribute their modified zone to all
>the servers in the NS set. (frequent assumption is 0 seconds)

>b) Forget about the possible impact of zone expiry when secondary server
>can not reach distribution server.

>c) Forget about maximum TTL in zone

I'm not sure where you are going here - but C isn't a problem in 
caches that do TTL trimming.   A & B aren't limited to being DNSSEC 
issues.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?