Subject: Re: [dane] Draft for serializing DNSSEC chains

From: Matt McCutchen <[email-masked]>
Date: Wed, 06 Jul 2011 20:09:49 -0400

On Thu, 2011-06-30 at 15:04 -0400, Phillip Hallam-Baker wrote:
> This approach solve the use cases and requirements stated in the Use
> cases and requirements document. It does so without requiring the end
> point client to have access to a DNSSEC enabled resolver.

For positive assertions (assurances), yes.

> It appear to me that it is considerably better than the scheme
> proposed in the Hoffman et. al. draft

Better in that the client doesn't have to talk to DNS servers.
draft-ietf-dane-protocol is better in that the server's cooperation is
not needed.  E.g., my mail client is using DANE for
mail.mattmccutchen.net, which points to a DreamHost mail server with a
self-signed cert I don't control.

> and it has the benefit of actual deployed code.

Depends on whether you count my use of nss-dane for my personal browsing
and email as "deployment".  :)

> It does not address the issue of security policy, promiscuous use of
> SSL, strict security etc.

Correct.

> but that is not a necessity.

Not sure what you mean by "necessity".  Restriction of TLS server
credentials is in the use cases doc.  Assurance and restriction of TLS
server credentials could conceivably be achieved via separate
mechanisms, but I support the WG's current approach of doing those two
together and leaving the other kinds of restrictions out of scope.

> The question that comes up as far as security policy is concerned is
> how recent a signature should be to be recognized. Should this type of
> self signed cert be valid for an hour, a day a week, a year, a decade?

Why should we second-guess the RRSIG validity?  Or, if fancier semantics
are desired, why should they be specific to DANE, rather than
incorporated into DNSSEC?

-- 
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 6 Jul 2011 21:32:10 -0400

> incorporated into DNSSEC?

Because the RRSIG validity could outlast the ownership of the name and
because there is no revocation mechanism.

If RRSIGs are valid for a decade, one compromise of one private key at one
time in history can poison all future use of that domain.

A domainer could create themselves some chains then sell the domain name.

I think that pretty much excludes respecting  chains for more than a year.

A PKI chain of trust is merely an assertion. The rules of PKIX and/or DNSSEC
merely define the consistency of the statement. The job of deciding what
inferences to draw from a valid chain lies with the browser.

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jul 2011 10:49:02 +0100

> time in history can poison all future use of that domain.

No, because the validity period for signatures in parent zones isn't that
long. For instance root zone signatures last just over a week.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon: Northwesterly, becoming cyclonic for a time in north, 5 to 7,
decreasing 4 in west later. Rough or very rough, becoming moderate or rough.
Rain or squally showers. Moderate or good.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 09:24:20 -0400

> long. For instance root zone signatures last just over a week.

The attack can be easily defeated if DNS registrars use different keys for
every DNSSEC hosted domain and roll them when required.

That requires a greater degree of competence on the part of registrars than
is likely to exist. Many registrars are pure marketing. I know of at least
one that does not have a single member of technical staff.

If the root zone is going to roll every week it is going to be necessary for
these certs to constantly re-issue in any case.

Taking up another thread, the point about compatibility with existing uses
of self-signed certs is well taken.

OCSP is going to work much better as a technical basis for the scheme. It
also works much better in terms of pulling through technologies that are
valuable and useful for other purposes. To make this approach to DANE work,
servers are going to have to deploy code to staple OCSP responses and
refresh their OCSP tokens from an appropriate source (DNS records or pull
from the CA).

I think I can see a collection of mechanisms here that present a win-win for
all concerned. Nobody gets everything they might want in the way they
prefer, but everyone gets something of value and everyone gets the
functionality they want.

---

From: Tony Finch <[email-masked]>
Date: Thu, 7 Jul 2011 15:00:22 +0100

> every DNSSEC hosted domain and roll them when required.

Registrars have no control over a zone's keys. That is a matter for the
DNS hosting provider.

> these certs to constantly re-issue in any case.

No, the root zone is re-signed weekly. The root ZSK is rolled quarterly.

But yes, I have already said you have to reconstruct a serialized DNSSEC
chains of trust frequently.

Remember that DNS keys have no explicit lifetime. The validity period is
part of the signatures, and you control replay attacks by the frequency of
re-signing. Rolling keys is only a prophylactic for disaster recovery.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Sole, Lundy, Fastnet: West or southwest 5 to 7, decreasing 4 at times. Rough
or very rough. Rain or squally showers. Moderate or good.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 07 Jul 2011 10:08:14 -0400

On 06/07/2011 9:32 PM, Phillip Hallam-Baker wrote:
>
>
> On Wed, Jul 6, 2011 at 8:09 PM, Matt McCutchen <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>

If the ownership of the name changes then the contents of the DS should 
have changed in such a way that the old KSK that authorized the DNSKEY 
in the old operators zone is not listed anymore --> all old signatures 
will not be accepted i.e. revoked.

>
> If RRSIGs are valid for a decade, one compromise of one private key at
> one time in history can poison all future use of that domain.
>
in practice it is hard.
There are two dimensions to look at here:
How long can a record remain in a cache?
    No signed record will be cached for longer than the TTL on the record.
    In addition number of resolvers cap how long a record can be stored 
(think day or few days).
    In addition oldest records are thrown away when allowed memory is 
exhausted.
    In addition most resolvers forget the contents of the cache when 
restarted.

How long can a signed record be "replayed" by an attacker after the 
record has been removed from the authoritative servers?
In this case the the "old" set will be believed if the attacker can 
inject it into the resolver, i.e. the attacker needs to see the query 
traffic or use blast of answers and hope it wins the race.
If the attacker can see the query traffic, RFC 3833 says in that case 
all bets are off as to get the answer but a validating resolver should 
detect what is going on and not proceed. The open issue is "does the 
current DS set in parent say the key signing the old DNSKEY set is to be 
believed?"
If the answer is yes then then the old set will be accepted.

The moral of this is to strongly suggest in an operating guide/BCP:
a)  do not sign records with signature lifetime greater than X days in 
the range [5..60].
b) if there is any concern with long lived DNSKEY signed set do a KSK 
rollover
c) Recommend that resolver do not believe a signed RRset past Y days 
signature inception day Y in the range [60..90]

> I think that pretty much excludes respecting  chains for more than a year.

IMHO one year is too long.

	Olafur

---

From: Martin Rex <[email-masked]>
Date: Thu, 7 Jul 2011 17:45:09 +0200 (MEST)

Phillip Hallam-Baker wrote:
> 
> Tony Finch wrote:
> 
> > Phillip Hallam-Baker wrote:
> > >
> > > If RRSIGs are valid for a decade, one compromise of one private key
> > > at one time in history can poison all future use of that domain.
> >
> > No, because the validity period for signatures in parent zones isn't
> > that long. For instance root zone signatures last just over a week.
> 

Existing, signed and long-lived RRSETs for a domain can be invalidated
by rolling the zone's signing key(s) in the parent zone.

Revocation mechanisms are notoriously complex, painful and unreliable.
Similar to (real-world) Kerberos, DNSSEC uses short-lived authorizations
and regular key replacement/rolling to obviate revocation entirely.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 11:53:45 -0400

I agree that revocation mechanisms are a big pain. I was not arguing for a
revocation mechanism, I was arguing against a long lived key.

I much, much prefer to have short lived keys than a revocation mechanism. If
we were to redesign PKI from scratch I would get rid of the revocation
mechanism entirely and require certs to be valid for no more than 24 hours.
In a key centric model like XKMS, certs are not necessary at all.

I think we are all in violent agreement here.