Subject: [dnsext] Engineering Requirements for Stub Chain Delivery

From: Dan Kaminsky <[email-masked]>
Date: Tue, 25 May 2010 05:28:00 -0400

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

Hello Everybody,

   I've been listening to your discussions regarding what to do about
the CD flag with great interest, as I've been working on implementing
a name server (and a stub resolver) to demonstrate the power of
DNSSEC.  As some of you have noted, there's a definite need for
certain stub resolvers to be able to acquire the full validation chain
for a given domain, even if that chain goes through CNAMEs or DNAMEs.
In my particular circumstance, I need the ability for end nodes to be
able to validate not merely (or even specifically) A records, but
CERT/SSHFP/etc. types for cryptographic keys.

   Put simply, end to end trust isn't negotiable; we need endpoints
able to get the full chain.  (I'm not trusting the name server at the
Coffee shop to tell me the certificate for anything.)  But I don't
have any more of an appetite than you guys do for forcing every random
client to harass the roots unnecessarily.  We have an enormous caching
layer, in the recursive server population, and it would really be
helpful if that caching layer could provide us precached chains.

   (As a note, this is why DNSSEC is fundamentally superior to
DNSCurve -- you can do end to end trust without losing the caching
layer.  Not that there isn't cool stuff in DNSCurve.)

   I've been working on determining the engineering requirements for
retrieving full chains to the root, from a DNSSEC server.  The two
core elements seem to be:

   1) In the presence of a request from the client, the server MUST
return a valid chain to the root, even when such chain traverses CNAME
or DNAME jumps.
   2) The request from the client SHOULD contain some sort of "hint",
describing the deepest DNSKEY that the client will trust as a chain to
the root.  For example, if a client has a valid DNSKEY for .com,
there's no need to repeat the chain from com to root.  Multiple hints
should be allowed.

   There does seem to be some desire around here to continue
supporting trust anchors in a non-root universe.  This isn't a model I
see ever scaling, but I _do_ like trust anchors as a way of allowing
even greater validation for particular delegations -- for example, a
company could use trust anchors for its own internal systems, rather
than trusting the registry and root it lives under.  It seems like
hinting should cover this trust anchor scenario just fine.

   In terms of encapsulation, some extension off EDNS0 looks like the
way to go here, though there's really no reason not to just emit the
hint DNSKEYs as an Additional RRset.

   Question for you guys:  Am I missing any engineering requirements
for my stub and name server?  I'm trying to capture the actual
in-the-field-necessary functionality for CD, and I think this hits it,
but I could be convinced otherwise.

--Dan

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 May 2010 02:14:31 +1000

In message <[email-masked]>, Dan Kaminsky writes:
> =A0=A0 I've been listening to your discussions regarding what to do about
> DNSSEC.=A0 As some of you have noted, there's a definite need for
> =A0=A0 Put simply, end to end trust isn't negotiable; we need endpoints
> able to get the full chain.=A0 (I'm not trusting the name server at the
> Coffee shop to tell me the certificate for anything.)=A0 But I don't
> client to harass the roots unnecessarily.=A0 We have an enormous caching
> =A0=A0 (As a note, this is why DNSSEC is fundamentally superior to
> layer.=A0 Not that there isn't cool stuff in DNSCurve.)
> 
> =A0=A0 I've been working on determining the engineering requirements for
> retrieving full chains to the root, from a DNSSEC server.=A0 The two
> =A0=A0 1) In the presence of a request from the client, the server MUST
> =A0=A0 2) The request from the client SHOULD contain some sort of "hint",
> the root.=A0 For example, if a client has a valid DNSKEY for .com,
> there's no need to repeat the chain from com to root.=A0 Multiple hints
> should be allowed.
> 
> =A0=A0 There does seem to be some desire around here to continue
> supporting trust anchors in a non-root universe.=A0 This isn't a model I
> than trusting the registry and root it lives under.=A0 It seems like
> =A0=A0 In terms of encapsulation, some extension off EDNS0 looks like the
> =A0=A0 Question for you guys:=A0 Am I missing any engineering requirements
> for my stub and name server?=A0 I'm trying to capture the actual

A stub needs to be able to query for chain elements it is missing.
It does not need them to be returned in a single query.  Such queries
will normally be satistfied by the caching server without having
to make additional queries especially if the caching server also
validates the reponses it gets (before or after sending them on).

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 May 2010 09:27:09 +1000

In message <[email-masked]>, Dan 
Kaminsky writes:
> > It does not need them to be returned in a single query. =A0Such queries
> A stub doesn't necessarily know what elements it is missing.  Consider
> foo.com CNAMEing through bar.com.  I need a chain to root, plus a
> RRSIG across the CNAME from foo.com to bar.com.
> 
> --Dan

You need to be able to validate the CNAME.  One path to the root.
You need to be able to validate whatever the CNAME points to.  A second path
to the root.

This is not difficult to work out.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 26 May 2010 11:46:00 +1000

In message <[email-masked]>, Dan 
Kaminsky writes:
> On Wed, May 26, 2010 at 1:27 AM, Mark Andrews <[email-masked]> wrote:
> >
> > In message <[email-masked]>=
> , Dan
> > Kaminsky writes:
> >> > It does not need them to be returned in a single query. =3DA0Such quer=
> ies
> >> A stub doesn't necessarily know what elements it is missing. =A0Consider
> >> foo.com CNAMEing through bar.com. =A0I need a chain to root, plus a
> > You need to be able to validate the CNAME. =A0One path to the root.
> > You need to be able to validate whatever the CNAME points to. =A0A second=
>  path
> > to the root.
> >
> OK.  What is the set of RRSIGs necessary for www.microsoft.com?

www.microsoft.com.      3582    IN      CNAME   toggle.www.ms.akadns.net.
toggle.www.ms.akadns.net. 300   IN      CNAME   g.www.ms.akadns.net.
g.www.ms.akadns.net.    300     IN      CNAME   lb1.www.ms.akadns.net.
lb1.www.ms.akadns.net.  300     IN      A       207.46.170.123
lb1.www.ms.akadns.net.  300     IN      A       207.46.170.10

For the anwer to www.microsoft.com be secure to the end application
you need to prove the each of the 3 CNAMEs above validate to secure
and that lb1.www.ms.akadns.net validates to secure.  You also need
to check the CNAME name chain itself makes sense.

Iterative nameservers do this all the time.

It really isn't harder in a stub resolver.  You look at the
www.microsoft.com CNAME's RRSIG.  This will give you a DNSKEY to
lookup. You then lookup the DS for that which gives you the DNSKEY
of the parent.  Repeat.  Do the same thing for toggle.www.ms.akadns.net,
g.www.ms.akadns.net and lb1.www.ms.akadns.net in turn.

If you attach a ephemeral cache to the validator you won't need to
do some of the lookups as there are commonalities in the trust
chains.

Mark

---

From: Dan Kaminsky <[email-masked]>
Date: Wed, 26 May 2010 03:17:07 +0200

---

From: Dan Kaminsky <[email-masked]>
Date: Tue, 25 May 2010 21:49:06 +0200

--Dan