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

From: "Marc Lampo" <[email-masked]>
Date: Mon, 4 Jul 2011 15:23:36 +0200 (CEST)

Hello,

You show a simple and most probably very frequent case :
Root --> tld --> customer.tld

But suppose "customer.tld" == "attacker.tld",
And "attacker.tld" can have a virtually unlimited number of delegated
subdomains
(a.b.c.d. . . .z.attacker.tld.)  each with their own DS and DNSKEY
information.

Can this lead to the script trying to achieve something which is
impossible ?
(like : is there an upper limit in size of the result ?)

Just to double check this security aspect ...

Kind regards,

Marc Lampo
Security Officer
EURid

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: 30 June 2011 10:47 PM
To: Osterweil, Eric
Cc: Adam Langley; [email-masked]
Subject: Re: [dane] Draft for serializing DNSSEC chains

...

1. . DNSKEY
2. . DNSKEY 
3. org DS
4. org DNSKEY
5. org DNSKEY
6. isoc.org DS
7. isoc.org DNSKEY
8. isoc.org DNSKEY
9. isoc.org TLSA

So my script polls for these records whenever the TTL expires, and issues
a new cert whenever the chain changes.  Seems like a pretty defined scope,
and like I said before, a plausible solution.

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 4 Jul 2011 15:35:47 -0400

In principle, that's true.  An attacker could also increase the size of the extension by choosing extraordinarily large keys (e.g., 4096-bit RSA keys).  But attacks of this character are not really all that big a concern, since the attacker is just DOSing himself.
--Richard

---

From: "Osterweil, Eric" <[email-masked]>
Date: Wed, 06 Jul 2011 13:34:33 -0400

On 6/30/11 4:47 PM, "Richard L. Barnes" <[email-masked]> wrote:

>>>> Managing the crypto in just
>>>> one system is hard enough, this seems to inheret baggage from two
>>>> crypto-enhanced systems...  :-/
>>> 
>>> I don't think it's quite that bad.  There's not really any PKIX baggage,
>>> since
>>> the all of the crypto validation comes from the DNSSEC extension.
>>> 
>>> The risk of falling out of sync may just be part of the trade-off for speed.
>>> It seems like there's a plausible solution (mod_dnssec_staple), so it
>>> doesn't
>>> seem like it necessarily has to be a blocking issue.
>> 
>> Again, I think the operational complexities are being vastly underestimated.
>> The certs have to be regenerated by authorities for websites based on
>> changes in DNS zones that exist anywhere along the validation chain.  In
>> particular, how many web server admins keep track of when the root changes
>> its ZSKs?  I know of the top of my head, but I still would find it a pain if
>> I had to go regen certs because someone popped a key somewhere... I still
>> don't even know how I would find that out?
> 
> It's not really so mysterious, it's just the chain from the name in the cert
> to the root.  If I'm trying to maintain a cert for isoc.org, I have to monitor
> 9 records (+RRSIGs)
> 
> 1. . DNSKEY
> 2. . DNSKEY
> 3. org DS
> 4. org DNSKEY
> 5. org DNSKEY
> 6. isoc.org DS
> 7. isoc.org DNSKEY
> 8. isoc.org DNSKEY
> 9. isoc.org TLSA

How much DNS monitoring is built into operational practices of cert users
now?  I know you COULD do the above.  I even have a pretty solid background
in doing it myself.  However, if a web server admin now needs to know to do
do this, know how to do this, and always actually do it, the process has
gone from automatic to quite complex, overnight.  Perl doesn't just happen
by itself. ;) 

> 
> So my script polls for these records whenever the TTL expires, and issues a
> new cert whenever the chain changes.  Seems like a pretty defined scope, and
> like I said before, a plausible solution.

So you're not issuing certs and inserting them into your zone and re-signing
all from cron?  Is that what you think everyone should do?  I'm not saying
this could never work, but don't you see how much operational complexity
(not to mention un-developed tools) you just implicitly required?

This is a straightforward design with very complicated operational
implications.

Eric