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

From: Martin Rex <[email-masked]>
Date: Sat, 2 Jul 2011 00:11:54 +0200 (MEST)

Stephen Farrell wrote:
> 
> On 30/06/11 21:26, Martin Rex wrote:
> > The purpose of the original validity in X.509 is twofold
> >   -- to maintain the commercial CA business model and invoicing
> >   for a subscription model (recurring fee or slightly reduced fee
> >   upfront for the entire period with no refund for unused time).
> >   -- to limit the growth of CRLs and to allow CAs to eventually
> >   dispose of their old keys and retire CRL publishing for a CA key.
> 
> Not part of the argument on this, but I believe the above
> is incorrect.

Yes, I'm sorry.

Admittedly, I was ranting completely free of historic facts here,
describing how X.509 Validity is actively employed today and how it
could be used in areas where PKI/X.509 is used on the internet today.

It's been only a couple of years that I got more deeply involved
with PKI(X), and I know you've been working in this area for very
much longer than that.

> 
> X.509 was originally the authentication framework
> for X.500 intended to allow DUAs to authenticate to directories.
> For that use-case, an expiry is quite appropriate. Of course
> notAfter is a PITA in some other cases and has given rise to
> some parts of a business model. But I don't believe that either
> of the above reasons were the original intent at all.

While it might be difficult to believe (due to my occasional temper),
I do appreciate clarifications on historic evolution that caused
technology to become what we've got today, especially from folks
who do know more about those events than I do.

-Martin

---

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

On 6/30/11 9:14 PM, "Tony Finch" <[email-masked]> wrote:

> On 30 Jun 2011, at 20:57, "Osterweil, Eric" <[email-masked]> wrote:
>> 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...
> 
> No no no. Key lifetimes are not a problem. They are measured in years.

Where do you get this data?

> You 
> need to care about signature lifetimes which are measured in days.

Where do you get this data?

I have been tracking both of the above (and putting it online for others to
see) for years and my view does not match yours.
 
> A web server SSL cert with an embedded DNSSEC trust chain needs to be
> regenerated daily at least.

... Because it cannot be allowed to become stale... However, this WILL
happen as an operational inevitability.  These things will get out of sync
and will become an attack vector.  Adding this level of indirection weakens
the security of the system.

Eric

---

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

On 6/30/11 4:26 PM, "Martin Rex" <[email-masked]> wrote:

> Osterweil, Eric wrote:
>> 
>>> 
>>> I believe the RRSIG validitiy is more in the matter of hours to days.
>> 
>> It varies, and is set by each zone.  Look at this for the current spectrum:
>>     http://secspider.cs.ucla.edu/images/key-lifetimes.png
>> 
>>> 
>>> And for DNSSEC to work smoothly, there are transistion periods for
>>> DNS key rollover, so that when correctly rebuilding the to-be-signed
>>> data from currently valid data (rather than blindly resigning old
>>> data when RRSIG expires), the problem you are describing might not
>>> exist.
>> 
>> 
>> In DNSSEC, yes, rollovers are handled "smoothly", but what keeps the cert in
>> sync?  If a cert exists for (say) a month, but a key rollover happens on
>> week 1 of the cert's lifetime, then the rollover will have completed long
>> before someone plans to re-examine and regenerate their cert.  Moreover, how
>> often do people roll their certs now?  I ask because the existing behavior
>> is a much better indicator of future behavior than what one _hopes_ people
>> will do.  Why do you think cert owners will suddenly know how to manage the
>> cross system dependencies?
> 
> 
> For use with DANE, you really want your X.509 Validity to be far far far
> into the future so that it will NEVER happen that you have to replace
> your certificate because of PKIX-style expiration.  If you're using
> a cert issued by a CA (such as from the TLS X.509 PKI) then the
> server cert lifetime will be subject to their policies, of course.

Then, I read from this that if you use a cert in DANE, then your cert will
have an increasing increasing increasing divergence from the DNS chain of
trust?

> When a server certificate is _not_ from a traditional PKI, but from
> your own CA or self-signed and distributed through DANE, then you
> do NOT want any certificate validity to inflict unnecessary
> administrative overhead.  The validity of the certificate
> is entirely governed by the existence of a signed DANE record
> refering to that cert.  And the cert becomes automaticlly invalid
> as soon as its DANE record is deleted from the DNS zone and the
> RRSIG of any existing/published DNS records expire.

I see two issues with the above:
1 - Not wanting to "inflict unnecessary administrative overhead" is a very
good goal, but it is not achieved just because you say so.  My whole point
is that this approach causes the implicit NEED for additional overhead.
Operators now need to track additional information external to the cert in
order to know when they need to change it!  Using DNS for DNSSEC obviates
the need for this additional overhead.
2 - The cert becoming invalid when the DANE record removed has no bearing on
the concern I raised.  The concern comes from the way in which the record is
validated.  If you use the embedded chain of trust that has been compromised
and mended in the DNS, then the cert is out of date.

Eric