Subject: [keyassure] Signature TTL Re: Validation signaling and sequencing

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 10:36:47 -0400

Could someone familiar with the DNSSEC specification set tell us if
there is a maximum TTL specified there?

I took a look but could not find one. I am pretty sure that 68 years
is longer than most people would want to accept a signature for.

If not, the specs should specify a time period or there will be an
interoperability issue.

On Wed, Sep 8, 2010 at 3:14 AM, Tony Finch <[email-masked]> wrote:
> On 7 Sep 2010, at 03:13, Douglas Otis <[email-masked]> wrote:
>
>> Exploits that abuse a domain are often measured in hours.  When authorities decide that a domain's public key is being used deceptively, its existence in cache can easily outlive the life of such domain.  Should there be a maximum TTL enforced for public keys and certificates stored in DNS?
>
> No, but it can be a recommendation. There's also OCSP.
>
> Tony.
> --
> f.anthony.n.finch  <[email-masked]>  http://dotat.at/
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

--
Website: http://hallambaker.com/

-- 
Website: http://hallambaker.com/

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Sep 2010 07:41:09 -0700

>there is a maximum TTL specified there?

Why is that relevant for this list? Maybe ask on DNSEXT.

>is longer than most people would want to accept a signature for.

Right.

>If not, the specs should specify a time period or there will be an

Can you be more specific about the interop issue you see?

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 10:48:44 -0400

> there is a maximum TTL specified there?

No, of course not.  That's an operational matter, not a matter of
protocol.

As a matter of practical consideration, you'd better not have a TTL
that allows expired RRSIGs to hang around in caches.

> is longer than most people would want to accept a signature for.

Yes.  Don't Do That (tm).  Nothing in the DNS protocols make it
protocol-invalid to create circular dependencies or circular
CNAME/DNAME chains, either.  That doesn't mean you should just go out
and do it.

> If not, the specs should specify a time period or there will be an

What issue?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 11:59:15 -0400

The issue Doug raises that seems perfectly valid to me is that if we
are using this mechanism for key assurance, signers are going to need
to know what they can expect from verifiers.

For example, say that Fred decides that he is not going to accept
signatures that are older than an hour. Likely he is going to be
disappointed in his use of key assure.

Contrawise, say that Mary decides that since a year is the standard
interval for certs, she is going to use that period for her DNSSEC.

This is an implementation detail that has to be specified in the key
assure specification if the spec is going to be interoperable in
practice.

Validators need to be told that they SHOULD NOT accept signatures
older than a specific age. Signers need to be told that they MUST
ensure that the zone is resigned within a specific interval.

This is not something that can be left to be determined at the site
level. The protocol can only work if the signers and validators have
agreement. if the protocol leaves this important detail out it will
emerge as an unstated defacto implementation and operational
constraint that is not actually documented anywhere. That is a really
bad practice.

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 17:09:06 +0100

On Wed, 8 Sep 2010, Phillip Hallam-Baker wrote:
> older than a specific age.

The expiry time is explicit in the RRSIG record.

> Signers need to be told that they MUST ensure that the zone is resigned
> within a specific interval.

This is an operational decision for the signer. There are some specs
working through the DNSOP WG which provide guidelines. See RFC 4641 /
draft-ietf-dnsop-rfc4641bis, RFC 5011, and
draft-morris-dnsop-dnssec-key-timing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 12:13:48 -0400

> interval for certs, she is going to use that period for her DNSSEC.

If we're going to start specifying operational rules as part of a
protocol, we could at least try to keep separate the various details
of the things we're talking about.  The phrase, "that period for her
DNSSEC," doesn't make any sense.

There are several different timing parameters that affect zone data,
and they interact with one another and with caches.  Some of these are
explicitly called out in zone data, such as the TTL on RRsets, the
initiation and expiry times of RRSIGs, and the negative cache and zone
refresh and expire times in the SOA record (to name a few).  Others
are implicit in operation, such as the time it takes for data changes
in a zone to be visible on the Internet, for it to be consistent on
all the authoritative servers, and the actual key lifetimes of the
DNSKEYs in use.

If what you're saying is that, for interop to be possible, we have to
specify the complete model of all of that, I say you're wrong.  That's
completely outside the scope of this work.  It's true, of course, that
a sentence needs to go into the Security Considerations section to
indicate that the timing parameters of the DNS and of DNSSEC operation
are relevant and need to be taken into consideration when using the
DNS for key information.  But anything beyond that is policy, not
protocol, and it's not a topic here.  We are not going to be able to
write a protocol that is completely idiot proof.  The idiots are too
clever.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Sep 2010 09:13:36 -0700

>assure specification if the spec is going to be interoperable in

Let me try again: can you give a *specific* example of where interoperability will be affected? So far, nothing you have said have any effects on interoperability.

>ensure that the zone is resigned within a specific interval.

We fully disagree here. You seem to want to jam your preferred policies down other people's throats. That has not proven effective or useful in the IETF.

>constraint that is not actually documented anywhere. That is a really

These bold statements of what must happen should be backed up with some real technical reasoning.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 12:29:44 -0400

You can't have a structure that attempts to roll the entire Internet
PKI under a single root key and then wash your hands of the messy
implementation details.

The people who write Web browsers need to have actual numbers that
they can plug into their code. Otherwise the default will be 68 years
and we know that that is unacceptable. It would mean that anyone who
ever gets control of a DNS name at any point can effectively poison
its use for close to a human lifetime.

I understand the issues of jitter and cache latency and the rest that
make specifying a time difficult to define. They are beside the point
here.

Once those numbers are plugged into the code they are going to set the
operational requirements for all DNSSEC deployments. If people start
using keyassure and just one widely used browser has a one hour expiry
specified then that is going to be a forcing function on operations.

So no, this is not your own personal preference any more. It is not a
matter of taste or site policy. A consequence of deploying keyassure
will be that every site that uses DNSSEC is going to have to comply
with the time constants embedded in the browsers.

This group cannot change that fact. The only thing they have influence
over is whether those constants are known and published or if they are
magic numbers representing 'folklore'.

The reason that this problem has not appeared until now is that nobody
is actually using DNSSEC at the application level and so the time
constants have absolutely no consequence.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 12:46:18 -0400

What numbers are missing here?  There are three relevant timers, all  
specified in places where browsers can read them, without needing to  
hard-code anything:

X.509 validity intervals are specified in the cert.
RRSIG validity intervals are specified in the RRSIG record
DNS TTLs are specified in the various RRs.

At a standards/interop level, there's nothing to be said about the  
absolute values of these numbers -- that's an operational issue.  The  
closest thing that makes sense is to recommend that their values have  
certain relationships, e.g.:
RRSIG expiry >= DNS TTL (as Andrew suggested)
X.509 expiry >= RRSIG expiry

--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 8 Sep 2010 09:54:02 -0700

>PKI under a single root key and then wash your hands of the messy

Good! No one here has proposed "a structure that attempts to roll the entire Internet PKI under a single root key".

>they can plug into their code.

No, they don't. That's what notAfter dates in PKIX certificates and DNS TTLs are for. Or are you saying that those two mechanisms that have been in use for decades don't work? If so, please give specific examples.

> Otherwise the default will be 68 years

That's utter nonsense, Phill. Please show examples on the Internet where DNS TTLs or RRSIG validities default to that value.

>its use for close to a human lifetime.

This statement shows a profound misunderstanding of DNS caching. To the best of my knowledge, no DNS resolver stores cached data on disk and restores it after a reboot. Further, cache-clearing is a common operational process used by ISPs and is supported by all the DNS resolver software I have seen.

>make specifying a time difficult to define. They are beside the point

Quite right. We are trying to reach closure here on a WG charter: you bringing up issues that you admit are beside the point is not useful.

>specified then that is going to be a forcing function on operations.

Again, please give concreted examples, not grandiose pronouncements. If you can't be specific by showing how a browser's that implements an internal maximum expiration will affect interoperability, please consider not repeating yourself again.

>with the time constants embedded in the browsers.

See above.

>magic numbers representing 'folklore'.

See above.

>constants have absolutely no consequence.

Another reason might be that, when applications do use DNSSEC, they actually follow the DNS protocol correctly. Or, if they choose not to pay attention to DNS TTLs, they will find out quickly enough that there is a problem and fix it.

Phill, this is getting a bit silly. If you don't understand DNS TTLs or basic DNSSEC concepts like validity intervals, you should definitely go read up on them yourself. Asking for help is one thing, but going off and making definitive statements about what Absolutely Must Happen when you still don't understand the technology is not helping us get to closure on a charter. Please consider making more constructive contributions.

--Paul Hoffman, Director
--VPN Consortium

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 12:54:54 -0400

The operational requirements of running a DNSSEC installation are
going to be dictated by the shortest value of MAX_SIG_AGE that a
widely deployed browser specifies in the following test

if (current-time - signing_time (cert_record) > MAX_SIG_AGE) {
      reject_key =- true;
      }

If there is no such test the browser will accept signatures that are
68 years old.

On Wed, Sep 8, 2010 at 12:46 PM, Richard L. Barnes <[email-masked]> wrote:
> At a standards/interop level, there's nothing to be said about the absolute
> values of these numbers -- that's an operational issue.  The closest thing
> that makes sense is to recommend that their values have certain
> relationships, e.g.:

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 18:12:39 +0100

> If there is no such test the browser will accept signatures that are

They won't be able to validate old signatures because the key chain will
have changed.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:14:40 -0400

Paul,

When I do not understand something I find out about it.

It appears that when you do not understand something you instead
assume that the reason the other person does not agree with you is
that they don't understand the subject.

That appears to be where our approaches differ.

Now I have posted very specific examples that illustrate Doug's
original point. You on the other hand have made absolutely no effort
to understand the issue. You have posted nothing substantive on the
point, you merely re-iterate your own point and make no effort to
demonstrate that you understand mine.

We have descended to a sufficiently deep level in the DNSSEC/PKIX
stack that I seriously doubt that there is even one individual on the
planet who fully understands all the implications. And I am absolutely
certain that if that individual were to exist that it is not you.

My principle concern in the chartering of a WG in this area is
precisely the fact that in the past the DNSSEC world has tended to fix
on glib answers and unfounded assurances that have since proven to be
worthless.

Either there has to be a statement in the draft about a minimum value
for maximum signature age that all clients have to support or it has
to be shown that the expiry of the signatures on the DS records in the
chain provide sufficient control.

My experience is that this is the type of conversation you want to
have before you write the draft rather than when an Area Director has
slapped a DISCUSS on the document.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:14:40 -0400

Paul,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:14:40 -0400

Paul,

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:14:40 -0400

Paul,

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Sep 2010 13:22:38 -0400

> its use for close to a human lifetime.

Yup -- but, how is this different to poisoning the NS / A / TXT / CNAME / anything else records?

W

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 18:23:49 +0100

> chain provide sufficient control.

Why can't this analysis be left to DNSEXT or DNSOP?

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:25:19 -0400

> They won't be able to validate old signatures because the key chain will

I agree.

So what we need in the draft is a statement to the effect that the
relying party SHOULD rely on the DNSSEC validation chain and MUST NOT
code arbitrary constants.

That means that in the case of a key being compromised with an
unacceptably lengthy time to live on the CERT record signature it is
going to be necessary for the parent zone to roll its keys and resign
the zone. So zones face a tradeoff, they can either commit to signing
frequently with a short validity interval or they can use a longer
interval and risk having to roll their KSK if they make a real muck of
it.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 13:34:11 -0400

Because the people who are reviewing any draft are going to ask this
type of question.

What would you accept if you were reviewing the draft for SECDIR? I
don't think I would accept 'go read this other draft' and I certainly
would not accept Paul's approach.

Whatever anyone thinks about the expertise of others present we are
writing this draft to be understood by people who do not understand
DNS or PKI at anything like the depth of the median participant in
this working group.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 13:35:59 -0400

On Wed, Sep 08, 2010 at 01:14:40PM -0400, Phillip Hallam-Baker wrote:

> original point.

I'm not sure I agree.  You have speculated about a preposteous state
of affairs in which people operate their zones in the manner of
low-grade morons.  I'm prepared to accept the possibility that there
are people who do that sort of thing, but I do not believe that it is
correct for a protocol to make stupid things impossible.  That's
operational guidance, not protocol.

As I already suggested, a line or two in a Security Considerations is
appropriate.  Attempting to produce a fully separate bunch of rules on
how to operate DNSSEC is not.  Indeed, if you want to get a DISCUSS
from some AD, a good way of doing it is to try to sneak into one
protocol a bunch of rules that attempt to govern some other protocol.

> on glib answers and unfounded assurances that have since proven to be

I think that if you wish to make sweeping generalizations about "the
DNSSEC world", you should go start up the SWEEPGEN WG.  Otherwise, I'd
appreciate it if you adopted a style slightly less needlessly
confrontational and insulting.

> chain provide sufficient control.

This places the burden of proof in the wrong place.  You're the one
claiming that RRSIG expiration and initiation times, TTLs, and the
myriad other timing devices in the DNS need additional rules in a
protocol planning to rely on DNSSEC.  You've offered not one shred of
evidence that this is needed in a protocol document, apart from some
hand-wavy claims and pseudocode about what "browsers" are going to do.
Either produce a real argument for your claim that shows a requirement
beyond what I already suggested, or drop your claim.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Tony Finch <[email-masked]>
Date: Wed, 8 Sep 2010 18:56:28 +0100

> code arbitrary constants.

Exactly, even though this should be obvious.

> interval and risk having to roll their KSK if they make a real muck of

And this is just what DNSOP is working on.

Tony.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 14:05:24 -0400

On Wed, Sep 8, 2010 at 1:35 PM, Andrew Sullivan <[email-masked]> wrote:
> low-grade morons.

Well maybe it is preposterous on your planet. What colour is the sky over there?

If you want security to work on this planet you build it so that it
can be operated by an admin who is hung over and dealing with user
questions every ten minutes.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 14:52:46 -0400

> Well maybe it is preposterous on your planet. What colour is the sky over there?

I have never, even once, seen a TTL of 68 years.  (I presume,
actually, you meant 63.  But whatever.)  Even the most perverse DNS
weirdos don't put TTL values in the billions in their zone files.
It's hard to take such suggestions seriously.

> questions every ten minutes.

Yes.  Also, the hung over sysadmin cum helpdesk cum BOFH has to have
tools beyond "vi" to support this sort of sophisticated operation.  Or
else s/he'll screw it up and leave a mess all over the Internet.  Go
know.  How that has anything to do with interoperation and what the
_protocol_ does is completely beyond me.

We are not building a user tool.  We're building the things that tools
need to depend upon.  Of course we have to have something to say to
tool builders and so on -- which is why it is appropriate to include
remarks that certain considerations need to be taken into account.  It
might even be the case that, after we have mechanisms for doing these
things in zone files, recommendations and BCPs and so on will emerge.
Those too ought to be documented by DNSOP.  But there's no reason to
make them part of the protocol, and making snide remarks to those
disagreeing with you will not make them naturally part of the
protocol.

Now, can we please move on?

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2010 12:00:59 -0700

> operational guidance, not protocol.

Andrew,

The concern was not about low-grade morons.  But with those using a 
large number of domains to sporadically support nefarious activities.  
The concern regarding the TTL of information carrying a level of trust 
was to better ensure rapid removal of such information found to support 
nefarious activities. Domains can be terminated within hours once 
nefarious activity is noticed, but expiry of cached data is determined 
by bad actors, and whatever maximum TTL limit was imposed by some 
recursive resolver.  Not all resource results necessarily need to have 
the same maximums imposed.

Tony suggested using OCSP to resolve this issue.  OCSP uses HTTP, but 
this is difficult to scale.  One solution being proposed has web sites 
obtaining their own OCSP status and relaying this status to browsers as 
part of the initial handshake protocol. This technique depends upon a 
digital signature of a CA.  The technique for doing this with TLS is 
defined in Section 3.6 of RFC 3546.

Should DNS key information depend upon recognized CAs to revoke 
information obtained from DNS?  A more scalable solution demanding less 
resources would have resolvers apply TTL limits for specific resource 
types to avoid concerns regarding prolonged retention of information 
detected as supporting nefarious activities.

-Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 15:07:07 -0400

Well in case you hadn't noticed, computer systems have absolutely no
common sense. So while a TTL of 63 years may appear absurd to you it
is certainly not absurd to a computer.

The consequence of not thinking these things through at the design
stage is that people then write code which causes large parts of the
Internet to drop off the net when a grad student injects a few BGP
packets with unexpected sizes and RIPE then pushes them at routers
that start aborting their BGP sessions like happened last week.

Protocol design is all a matter of the details.

Security protocol design is all about thinking about what happens when
people test the limits of your system.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 15:13:53 -0400

I don't think revocation is actually something that needs to be  
covered here, since DNSSEC already has a revocation story -- namely,  
set the TTLs and validity intervals short enough that revocation isn't  
an issue.  Like Warren observed earlier, the revocation concern here  
is the same as for A, NS, CNAME, etc.  If one of my servers is  
compromised, I "revoke" its access by removing its A record from my  
zone.  Nothing new here.

--Richard

On Sep 8, 2010, at 3:00 PM, Douglas Otis wrote:

> large number of domains to sporadically support nefarious  
> activities.  The concern regarding the TTL of information carrying a  
> level of trust was to better ensure rapid removal of such  
> information found to support nefarious activities. Domains can be  
> terminated within hours once nefarious activity is noticed, but  
> expiry of cached data is determined by bad actors, and whatever  
> maximum TTL limit was imposed by some recursive resolver.  Not all  
> resource results necessarily need to have the same maximums imposed.
>
> Tony suggested using OCSP to resolve this issue.  OCSP uses HTTP,  
> but this is difficult to scale.  One solution being proposed has web  
> sites obtaining their own OCSP status and relaying this status to  
> browsers as part of the initial handshake protocol. This technique  
> depends upon a digital signature of a CA.  The technique for doing  
> this with TLS is defined in Section 3.6 of RFC 3546.
>
> information obtained from DNS?  A more scalable solution demanding  
> less resources would have resolvers apply TTL limits for specific  
> resource types to avoid concerns regarding prolonged retention of  
> information detected as supporting nefarious activities.
>
> -Doug

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 8 Sep 2010 15:15:31 -0400

Doug,

I do not think this is necessary.

As Tony pointed out, there has to be a complete DNSSEC trust chain to
some root. Assuming that the root is managed with appropriate
time-outs it is always possible to void a DNSSEC zone signing by
installing a new KSK in the parent zone and working from there.

Even if the attacker has previously signed CERT records with a 63 year
expiry, the signature on the DS record for the zone will be a matter
of days.

So this is an issue that we can in fact reasonably push onto the
operations draft.

On Wed, Sep 8, 2010 at 3:00 PM, Douglas Otis <[email-masked]> wrote:
> The concern was not about low-grade morons.  But with those using a large
> number of domains to sporadically support nefarious activities.  The concern
> regarding the TTL of information carrying a level of trust was to better
> ensure rapid removal of such information found to support nefarious
> activities. Domains can be terminated within hours once nefarious activity
> is noticed, but expiry of cached data is determined by bad actors, and
> whatever maximum TTL limit was imposed by some recursive resolver.  Not all
> Tony suggested using OCSP to resolve this issue.  OCSP uses HTTP, but this
> is difficult to scale.  One solution being proposed has web sites obtaining
> their own OCSP status and relaying this status to browsers as part of the
> initial handshake protocol. This technique depends upon a digital signature
> of a CA.  The technique for doing this with TLS is defined in Section 3.6 of
> RFC 3546.
>
> Should DNS key information depend upon recognized CAs to revoke information
> obtained from DNS?  A more scalable solution demanding less resources would
> have resolvers apply TTL limits for specific resource types to avoid
> concerns regarding prolonged retention of information detected as supporting
> nefarious activities.
>
> -Doug

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 8 Sep 2010 22:28:01 +0200

We should also keep in mind that most recursive nameservers has a setting that trims down all TTLs to a given maximum - effectively stopping them from caching anything longer than some timea. The default value in BIND 9 it's 7 days, in Unbound it's 1 day.

	jakob

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2010 14:28:05 -0700

> installing a new KSK in the parent zone and working from there.
This does not address the concern regarding a means to ensure cached 
trust information will not prolong the support of nefarious activity 
even after a domain has been revoked.  Nefarious activity per domain 
often begins and ends in less than a day.
> expiry, the signature on the DS record for the zone will be a matter
When trust data might be retained for days in cache, enforcement will be 
much less effective, even when their response may take minutes.  This 
leaves enforcement with a very slow mallet in a high speed whack-a-mole 
game.
> So this is an issue that we can in fact reasonably push onto the
Revocation expediency would be better addressed by making minor changes 
in how this type of data might be handled in caches.  This would be 
changing the knobs available to operations to include separate settings 
for autonomous trust information.  It seems that caching should be 
limited to less than an hour, and perhaps as short as 5 minutes when the 
resource offers no other means for revocation.

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Sep 2010 17:36:28 -0400

> often begins and ends in less than a day.

You don't have that ability _today_.  What you're asking for is that
we formalize a mechanism where consumers of DNS data get to ignore the
TTL.  If you want such a mechanism (and "cache invalidation" tricks
have been proposed before), I suggest you take such proposals over to
DNSEXT.  It does not belong in a specification of this sort.  We're
using the DNS, not some other DNS-like technology that we're going to
invent on the fly.  DNS has certain limitations.  One of those is
caching.  You don't like that limitation, don't use the DNS.  

There are reasons to feel that caches can sometimes make already bad
things worse.  But we're not going to fix that up retail with every
RRTYPE that comes along.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 08 Sep 2010 15:19:30 -0700

On 9/8/10 2:36 PM, Andrew Sullivan wrote:
>  You don't have that ability _today_.

Did you read Schlyter's note?  This is _already_ being done on a general 
basis but for different reasons.

>  What you're asking for is that we formalize a mechanism where
>  consumers of DNS data get to ignore the TTL.

The recommendation would be for autonomous trust information to not be 
retained for more than 1 hour, where perhaps other types of information 
would not be retained for more than 24 hours, for example.  Key 
information affecting user's perceptions of trust will have different 
risk exposures from those related to IP addresses.

>  If you want such a mechanism (and "cache invalidation" tricks have
>  been proposed before), I suggest you take such proposals over to
>  DNSEXT.

This is not about a trick.  This is about providing separate maximal TTL 
setting for trust related resources.

>  It does not belong in a specification of this sort. We're using the
>  DNS, not some other DNS-like technology that we're going to invent on
>  the fly. DNS has certain limitations. One of those is caching. You
>  don't like that limitation, don't use the DNS.

The goal of this effort was to offer alternatives to CAs for obtaining 
information used to secure transactions.  This alternative should offer 
expeditious revocations.  Insuring reasonably expeditious cache expiry 
of these resources can supplant more difficult to scale and less 
effective alternatives.

>  things worse. But we're not going to fix that up retail with every

What is being proposed rises above being about just another resource 
record type.

-Doug

---

From: Tony Finch <[email-masked]>
Date: Thu, 9 Sep 2010 01:55:44 +0100

On Wed, 8 Sep 2010, Richard L. Barnes wrote:

> I don't think revocation is actually something that needs to be covered here,
> since DNSSEC already has a revocation story -- namely, set the TTLs and
> validity intervals short enough that revocation isn't an issue.

It's the TTLs that set the revocation time limit, not the signature
validity intervals. The TTL has to be shorter than the validity interval
(because they must expire from caches and be replaced by new signatures
before they become invalid) and signatures have to be re-validated after
they expire from a cache.

Tony.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 09 Sep 2010 12:49:20 +1000

In message <[email-masked]>, Jakob Schlyter writ
es:
> We should also keep in mind that most recursive nameservers has a setting tha
> t trims down all TTLs to a given maximum - effectively stopping them from cac
> hing anything longer than some timea. The default value in BIND 9 it's 7 days
> , in Unbound it's 1 day.
> 
> 	jakob

And it is recommended in RFC 1035.

   - As an optional step, check the TTLs of arriving data looking
     for RRs with excessively long TTLs.  If a RR has an
     excessively long TTL, say greater than 1 week, either discard
     the whole response, or limit all TTLs in the response to 1
     week.

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

---

From: [email-masked]
Date: Thu, 9 Sep 2010 06:20:44 +0000

>      the whole response, or limit all TTLs in the response to 1

	and yet, as late as 1996, it was common to see TTL values that 
	exceeded a week - this text - quite literally - is an example.
	I don't see this as a recommendation - more of an explaination.
	some peope don't see a weeklong TTL as "excessive".

--bill

---

From: David Conrad <[email-masked]>
Date: Wed, 8 Sep 2010 20:28:44 -1000

Bill,

> 	some peope don't see a weeklong TTL as "excessive".

You mean you were seeing TTLs > 1 week inside a cache (in some not experimental and/or seriously borked resolver)?

Regards,
-drc

---

From: [email-masked]
Date: Thu, 9 Sep 2010 06:47:46 +0000

> there is a maximum TTL specified there?

	DNS has a max TTL specified
	DNSSEC has signature validity periods

	it used to be possible to have either the validity period exceeed the TTL
	one could also have a longer TTL than a signature validity interval.

	Current specification for sig validity period is defined in RFC 4034,
	3.1.5.  Signature Expiration and Inception Fields

	(your 68 years)

	and the actual calculation is defined here:

	3.1.8.1.  Signature Calculation

	which effectively locksteps the TTL and the signature validity period, e.g..
	no ambiguity wher one out-runs the other.

> is longer than most people would want to accept a signature for.

	most, but not all...

> If not, the specs should specify a time period or there will be an

	this seems somewhat orthoginal to the key/hash/cert that one finds
	in the RRset that you validate.

--bill

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Sep 2010 09:56:52 -0400

On Wed, Sep 08, 2010 at 10:28:01PM +0200, Jakob Schlyter wrote:
> We should also keep in mind that most recursive nameservers has a
> setting that trims down all TTLs to a given maximum - effectively
> stopping them from caching anything longer than some timea. The
> default value in BIND 9 it's 7 days, in Unbound it's 1 day.

Maybe I haven't made the point I was trying to make clearly.  Let me
try again.

First, it's certainly true that a cache could throw away data after
some period of time, and that the TTL does not make any kind of
promise about how long things _will_ be in cache.  After all, there is
no requirement that a resolver cache things at all, which is the same
as the resolver pegging things to 0.  That's all operational practice
and implementation detail, however, and none of it is part of the
protocol.

What is being proposed is that, for _just_ this RRTYPE, there either
be some maximim TTL built into the rules about the TTL, or else there
be some advice to resolvers that, whatever the TTL be, any cache trim
the TTL down to a lower value.  That is, it's RRTYPE-specific advice.
That cache might be in the end client.  This is supposed to be part of
the protocol itself, and not some operational advice or suggestions
about sane implementation.  (If it's the latter, then what I've
already suggested about a line or two in the Security Considerations
section of any document would be enough.)

There are three problems with this.  The first is that this
effectively requires updating RFC 1034, because the definition of
TTL in section 3.5 there does not even remotely suggest that TTLs need
special handling depending on the RRTYPE.  Even DNSSEC doesn't do
this, despite the fact that you probably never want to cache an RRSIG
RR past its expiry time.  (Again, implementations might do something
nice anyway, but it's not required by the protocol.  This is a sharp
pointy edge of the protocol.)

Second, depending on exactly how the requirement is worded, this
changes any proposed RRTYPE from just another RRTYPE that can be
handled simply and qualify under the "unknown RRTYPE" rules (and which
can therefore get an RRTYPE code assigned by expert review) into a new
case of server-side processing.  Every intermediate cache might need
to understand the RRTYPE to handle it correctly, and in any case you
certainly need signalling to indicate that you really do understand
that RRTYPE and it's ok to send it.  This would mean that to use this
RRTYPE, we need to reformat the DNS.  Since the point of the present
effort is to add something trivially supported, I think something
requiring special handling is a bad idea.

Third, supposing we don't require server-side handling rules, it turns
the entire approach into an excellent mechanism for breakage.  Suppose
I want to use this RRTYPE but I don't upgrade my server.  I can
accidentally set the TTL too long (probably by accepting the default
for the zone).  The RRTYPE will load and serve just fine, because the
server supports the unknown RRTYPE.  But the RR-aware client will see
the long TTL and start throwing away those answers.  Unfortunately,
that client is almost certainly behind a cache that has not looked at
the RR, and has cached it according to normal TTL processing.  The
client will see that cached entry until the TTL expires.  It will of
course keep refusing to use the data in the result (assuming we have
the rule Doug is arguing for), but the site is broken.

None of this strikes me as a good idea in order to try to engineer a
solution to "bad behaviour".  If we wish to provide operational advice
to resolver operators, that's one thing.  If we wish to make protocol
rules about how long a given RRTYPE may be cached, it's quite
another.  It makes assumptions about the DNS that aren't true, it may
require special processing (which changes the deployment effort from
"do it tomorrow" to "reformat the Internet"), and it makes the RRTYPE
much more brittle for use than it needs to be.  Solving bad behaviour
on the Internet will not be helped by a half-measure that can cause
surprising side effects.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.