Subject: [dane] revocation of keys or certificates

From: Christian Becker <[email-masked]>
Date: Sun, 03 Mar 2013 11:16:12 +0100

Comparing PKIX and DANE I regularly get asked about the certificate
revocation in DANE. To me revocation is straight forward: you change
keys in the TLSA record. BUT what if the key was propagated with a large
TTL to the caches of the worlds DNS servers. In that case the revocation
process can only be considered done when the TTL has elapsed.

Is that the right perception and are there any solution for that, except
of a recommendation to keep the TTL small?

Thanks,
Christian

---

From: Yoav Nir <[email-masked]>
Date: Sun, 3 Mar 2013 11:33:02 +0000

Hi Christian

There may be ways in some environments to push updates, but it's neither universal nor reliable. So the perception is correct. It's not much different from waiting for the NextUpdate time of the CRL.

And the solution is also the same: short TTLs, frequent CRL updates, short response validity interval.  With either technology it's a trade-off between timely revocation and load on the issuer.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Becker
Sent: Sunday, March 03, 2013 12:16 PM
To: [email-masked]
Subject: [dane] revocation of keys or certificates

Comparing PKIX and DANE I regularly get asked about the certificate revocation in DANE. To me revocation is straight forward: you change keys in the TLSA record. BUT what if the key was propagated with a large TTL to the caches of the worlds DNS servers. In that case the revocation process can only be considered done when the TTL has elapsed.

Is that the right perception and are there any solution for that, except of a recommendation to keep the TTL small?

Thanks,
Christian

---

From: Richard Barnes <[email-masked]>
Date: Sun, 3 Mar 2013 10:44:27 -0500

Just to be clear, CRLs only help here as an analogy.  As I read the DANE
specs, a relying party would not be required to do CRL checking on a cert
with a Type 3 TLSA assertion, because that assertion says that the public
key in the cert is to be used as a trust anchor.  (And TAs are by
definition exempt from further validation.

Your initial instinct was right.  TLSA associations are secured with
DNSSEC, so the follow the same models for revocation, rollover, etc.  So
short TTLs are the only tool you have.

--Richard

On Sunday, March 3, 2013, Yoav Nir wrote:

> Hi Christian
>
> There may be ways in some environments to push updates, but it's neither
> universal nor reliable. So the perception is correct. It's not much
> different from waiting for the NextUpdate time of the CRL.
>
> And the solution is also the same: short TTLs, frequent CRL updates, short
> response validity interval.  With either technology it's a trade-off
> between timely revocation and load on the issuer.
>
> Yoav
>
> From: [email-masked] <javascript:;> [mailto:[email-masked]<javascript:;>]
> On Behalf Of Christian Becker
> To: [email-masked] <javascript:;>
> revocation in DANE. To me revocation is straight forward: you change keys
> in the TLSA record. BUT what if the key was propagated with a large TTL to
> the caches of the worlds DNS servers. In that case the revocation process
> can only be considered done when the TTL has elapsed.
>
> _______________________________________________
> dane mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: James Cloos <[email-masked]>
Date: Sun, 03 Mar 2013 17:20:49 -0500

>>>>> "RB" == Richard Barnes <[email-masked]> writes:

RB> So short TTLs are the only tool you have.

And that really ought to be sufficient.  It is not at all uncommon to
have TTLs as low as an hour or even a minute for some RRs without any
significant impact on the dns servers.

And even if it is for a TLS server which gets so much traffic that a
short DNS TTL would have a noticeable impact on the hardware or net
pipes, that still will be *dwarfed* by the TLS load and traffic.

Some sites, typically those with very small or expensive pipes, may
(try to) force their caching resolvers to recheck less often than the
TTLs.  But even they tend to cache for no more than a day or two.

And there is the option to use a type 2 with one's own CA, CRL, ocsp
et al if that is more comfortable.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 3 Mar 2013 18:13:06 -0800

> And that really ought to be sufficient.  It is not at all uncommon to have
TTLs as low as an hour or even a minute for some RRs without any significant
impact on the dns servers.

It also has the advantage of being really simple, and thus less easy to fall
prey to some weird bug. If the TTL expires often, then the management
procedures are there to republish it often. If a certificate has a very long
life time, then renewals happen rarely, the procedures are not well tested,
and we do see silly mistakes happen.

> And even if it is for a TLS server which gets so much traffic that a short
DNS TTL would have a noticeable impact on the hardware or net pipes, that
still will be *dwarfed* by the TLS load and traffic.

The name server records are still cached, which cuts most of the impact on
the DNS infrastructure.

-- Christian Huitema

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Mar 2013 01:37:24 -0500 (EST)

On Sun, 3 Mar 2013, James Cloos wrote:

> And that really ought to be sufficient.

Just to clarify, it is the short RRSIGs that give you the "revocation"
of removing the record from the zone, not the short TTL. If your RRSIG
is set for 60 days, a short TTL does not prevent anyone from spoofing
your old key.

Paul

---

From: Christian Becker <[email-masked]>
Date: Mon, 04 Mar 2013 12:30:52 +0100

> is set for 60 days, a short TTL does not prevent anyone from spoofing

Wouldn't an elapsed TTL of RRSIG as well as an elapsed TTL of TLSA
trigger a question to the authoritative NS?
And aren't both versions prone to replay attacks, because there is no
absolute time involved? I could just record the TLSA and RRSIG records
and replay them after the key is "revoked" until the signature in RRSIG
is expired or the ZSK has changed.

Thanks again.
Christian

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 01:05:14 +0100 (CET)

Christian Becker wrote:
> revocation in DANE.

There is no revocation in DANE.

There is only expiration through RRSIG Signature Expiriation
and invalidation through zone key roll-over.

>
> In that case the revocation process can only be considered
> done when the TTL has elapsed.

TTL is meaningless here.  TTL's purpose is a mere guidance for caching,
TTL does not provide any security.  It is an unsigned(!!) DNS record attribute
that an intermediary can make up at will.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Mar 2013 14:11:39 +1100

> that an intermediary can make up at will.

TTL is a signed field but instead being a single value it is a
range.  A intermediary can change it but the receiver knows what
the range is supposed to be and can fix any attempt to set it to a
value that is out of range.

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

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 05:03:18 +0100 (CET)

Mark Andrews wrote:
> Martin Rex writes:
> > TTL does not provide any security.  It is an unsigned(!!) DNS record
> > attribute that an intermediary can make up at will.
> 

TTL is *NOT* signed.

While there is an original TTL field that is signed:
   http://tools.ietf.org/html/rfc4034#section-3.1.4

this will not prevent any intermediary (attacker) to produce
new DNS responses with TTLs less than or equal ot the original
TTL field whenever necessary within the remaing RRSIG lifetime.

-Martin

---

From: Mark Andrews <[email-masked]>
Date: Tue, 05 Mar 2013 15:33:25 +1100

> TTL field whenever necessary within the remaing RRSIG lifetime.

And the sematic difference is what?  When you produce a RRSIG you
are saying to the world "all these TTL values are valid".  It's
just short hand for generating TTL+1 RRSIG covering each possible
value.

Mark

---

From: [email-masked] (Martin Rex)
Date: Tue, 5 Mar 2013 05:45:16 +0100 (CET)

> just short hand for generating TTL+1 RRSIG covering each possible

The original question was whether TTL provides revocation.
No, TTL can not possibly provide revocation (for DNSSEC protected
DNS records), because it can be made up at will by an intermediary
attacker.  Only the RRSIG lifetime and rolling the zone key are
reliable in getting rid of DNSSEC protected data that is no longer
to be seen as valid.

It is like that "limited to one withdrawel per day" limit on
ATM cards that is implemented by an unprotected counter that
is stored on the ATM card itself.  The crooks with a
card reader/writer can simply reset that counter on the magnetic
strip after withdrawal and perform multiple withdrawels
(usually on ATMs of different banks) on the same day.

-Martin

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 5 Mar 2013 07:19:15 -0500

> (usually on ATMs of different banks) on the same day.

Martin and Mark, 
You are both right and neither fully wrong :-) 

For most practical cases we can think of DNS time based "revocation" as two different revocation times. 

old RRset TTL == is when an publisher of the record can assume that MOST resolvers will have purged the old record from their caches. This timer starts when the new RRset is distributed to the LAST authoritative server for the zone. 

Signature Expiration time == Absolute  time  upto which an ON-PATH adversary can reuse the old RRset and have it accepted by a targeted victim. 

The difference is the scope of the revocation, MOST vs Targeted, also if the adversary is ON-PATH then it 
can do lots of other things to the victim.
There are differences in "how much" ON-PATH the adversary is, in some cases they are listening to the query traffic on the write in other cases they have succeeded in redirecting DNS traffic to resolvers under their control.

---

From: James Cloos <[email-masked]>
Date: Tue, 05 Mar 2013 13:47:11 -0500

It looks like a let offline distractions get the better of me with my
previous post on this topic.

What I wanted to write is that, given that dns servers cope well with
very short RR TTLs, they also should cope well with short-duration RRSIGs.

-JimC

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Mar 2013 09:08:11 +1100

> very short RR TTLs, they also should cope well with short-duration RRSIGs.

Actually they don't.  TTL are relative times.  RRSIGs contain
absolute time.

TTLs say delete this in X seconds.
RRSIGs say stop believing this a YYYYMMSSHHMMSS.

If your clock is a day fast (a very real failure senario) it has
NO impact on how the TTL is interpreted.  It has a big impact on
how the RRSIG values are interpreted.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 8 Mar 2013 18:41:04 -0500

For security considerations, only the signature expiration time is significant.

The problem is that an attacker with control of the key could in
theory set the expiration time to 2099 or something stupid. But that
is already a known security consideration (or was). If the attacker
has only one RRSIG then it is sufficient to have a limit on the
lifetime of the RRSIG. But an attacker could also generate themselves
multiple RRSIGs for the whole time interval in question.

So ultimately it comes down to how the keys are managed in the
upstream zones and whether one of those can be rolled in the case of a
major compromise.

So there is a time window for attack in the case of administrator
incompetence, but I have a really hard time seeing how it can be
closed with a revocation system that was established through the same
root of trust.

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