Subject: Re: [dnsext] [dane] End of TTL during TLS setup

From: [email-masked]
Date: Wed, 22 Feb 2012 09:26:30 +1100

------- Blind-Carbon-Copy

To: Andrew Sullivan <[email-masked]>
Cc: [email-masked]
From: Mark Andrews <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Subject: Re: [dane] End of TTL during TLS setup
In-reply-to: Your message of "Tue, 21 Feb 2012 12:00:58 CDT."
             <[email-masked]>
Date: Wed, 22 Feb 2012 09:26:30 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> On Tue, Feb 21, 2012 at 05:38:17PM +0100, Martin Rex wrote:
> > 
> > To me that sounds _much_ too complicated.  The TTL on a DNS record
> > is not a security feature anyway, so I do not see a justification to
> > treat TTLs of TLSA records any different than TTLs on other DNS
> > records
> 
> I'd actually agree with this but for the text that was already there,
> which says that the negotiation has to complete before the TTL
> expires.  Your suggested alternative will not in some cases meet that
> requirement.  I presumed the WG had a reason to phrase it this way; if
> not, then your suggestion is better.
> 
> A

The important time is the RRSIG's expiration time of the RRSIG that
validated the RRset (i.e. you have to choose the correct one).  TTL
is a cache refresh parameter.  You will get TTL's of zero seconds
which means "use for this transaction" not "use within 0 seconds".

[TTL trimming is also something that is not well specified in RFC 4035
but that is dnsext fodder for as long as dnsext exists.  Personally I
thing it is too early to shutdown dnsext as DNSSEC is just begining to
be used widely enough for specification problems to start to surface
from applications. Bcc: [email-masked]]

- -- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

------- End of Blind-Carbon-Copy

---

From: Edward Lewis <[email-masked]>
Date: Thu, 23 Feb 2012 11:50:24 -0500

>------- Blind-Carbon-Copy

?, Well, I don't think this was meant to be private.

>from applications. Bcc: [email-masked]]

Before using the value in any field (of any protocol) you need to 
know what it is there.

The TTL is there to keep DNS cache contents fresh.  It's an estimate 
of how long the authority server thinks the data will remain constant.

The RRSIG expiry is the time at which the signature is no longer 
valid as proof of source authenticity and data integrity of the set 
it "covers."  In addition, the time fields in RRSIG are providing a 
defense against replay attacks and a rudimentary means of dealing 
with the need to revoke cryptographic-based credentials.

Neither of these address the correctness of the data, the timeliness 
of the data, the sequence of the data, etc.  The TTL is there solely 
to enable the caching mechanism and the RRSIG dates are there solely 
to protect the DNSSEC validation process.

Any other uses of those fields may engender unintended consequences.

Have we ever ended a Telnet session because the A record TTL'd out?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!