Subject: [dane] Opening issue #10: Considerations related to the comprimise of an intermediate CA

From: Ondřej Surý <[email-masked]>
Date: Tue, 16 Aug 2011 21:50:03 +0200

Hi,

as I promised I am opening another issue to solve.  This time I picked #10 since it seems to be far away from #7 and #29 which are discussed in the list right now.

It's seven months old and says:

> If an intermediate CA were compromised, then a DNS admin could
> obviate the revocation of the relevant CA cert by adding an RR.
> Not that likely, and detectable, but maybe worth a security
> consideration paragraph since such a case might be fairly
> catastrophic as-is, but would be made worse with DANE.

What does WG think?

O.
http://trac.tools.ietf.org/wg/dane/trac/ticket/10
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Martin Rex <[email-masked]>
Date: Tue, 16 Aug 2011 22:01:38 +0200 (MEST)

Ondrej Sury wrote:
> 
> #10 -- It's seven months old and says:
> 

IMO, DANE should never be conceived to obviate PKIX revocation in
any usage scenarios where PKIX revocation was designed and configured
into the PKI.  If revocation was set up (i.e. a CRL Distribution Point
extension or an OCSP AIA extension is present the relevant intermediate
cert), then this revocation mechanism MUST be used (as well).

DANE may additionally discontinue to provide an independent confirmation
for specific certs, but that is an entirely different issue.  DANE
records work closer to non-negative OCSP-responses than to CRL entries,
and OCSP seems to be a scheme to facilitate CRL processing rather
than to obviate CRLs/revocation.

-Martin

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 16 Aug 2011 13:45:19 -0700

+1

If it is revoked - then it is revoked.  DANE should never be able to
un-revoke any certificate.

jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Martin Rex
> Sent: Tuesday, August 16, 2011 1:02 PM
> To: Ondrej Surý
> Cc: [email-masked]
> Subject: Re: [dane] Opening issue #10: Considerations related to the
> comprimise
> 
> Ondrej Sury wrote:
> >
> IMO, DANE should never be conceived to obviate PKIX revocation in any
> usage scenarios where PKIX revocation was designed and configured into the
> PKI.  If revocation was set up (i.e. a CRL Distribution Point extension or
an
> OCSP AIA extension is present the relevant intermediate cert), then this
> revocation mechanism MUST be used (as well).
> 
> for specific certs, but that is an entirely different issue.  DANE records
work
> closer to non-negative OCSP-responses than to CRL entries, and OCSP seems
> to be a scheme to facilitate CRL processing rather than to obviate
> CRLs/revocation.
> 
> 
> -Martin
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Scott Schmit <[email-masked]>
Date: Tue, 16 Aug 2011 23:23:23 -0400

On Tue, Aug 16, 2011 at 09:50:03PM +0200, Ondřej Surý wrote:
> as I promised I am opening another issue to solve.  This time I picked
> #10 since it seems to be far away from #7 and #29 which are discussed
> in the list right now.
> 

The cases that come to mind are:

1) we've associated to an EE, but that EE is revoked

A couple of things could have happened here:
1a) the CA revoked the EE certificate because the EE certificate key has
    been compromised (likely because owner said so), and the DNS hasn't
    updated to reflect it--possibly because the cache hasn't expired yet
    or the DNS admin hasn't gotten around to updating the DNS yet. This
    is probably the typical case.
    - In this case, we definitely want to respect the revocation

1b) the CA mistakenly or maliciously revoked the EE certificate. I imagine
    this is rare.
    - While this is certainly inconvenient, the DNS admin can work around
      the problem by acquiring/generating a new certificate and updating
      the DNS accordingly.

For this case, it's better to treat the EE cert as revoked. CAs with a
habit of revoking EE certs inappropriately will not stay in business
long.

2) we've associated to an EE, but some CA is revoked

In this case, we can do the same as the above, but should we? The DNS
admin has said that the EE cert is correct. Why would revocation of a
CA cast doubt on the correctness of the EE certificate?

I suppose my attitude would change if people think it'll become common
practice for DNS admins to allow CAs to update the admin's zones
automatically on certificate issue. In that case, I'd suggest a security
consideration advising against it. ;-)

Of course, realistically, the cert and DANE record will probably need
replacement anyway if there is still a significant population of RPs
that are either unaware of or unwilling/unable to use DANE, because they
will be rejecting the certificate (unless they don't look at revocation
at all, in which case this whole issue is moot). But IMHO, that would be
the admin's/owner's call.

3) we've associated to a CA, but the EE is revoked

This case doesn't even affect the DANE association. Normal processing
applies.

4) we've associated to a CA, but that CA is revoked

In this case, we certainly want to treat the certificate as revoked--if
the CA certificate is revoked, it was probably compromised, and we can't
trust that the EE cert seen by the RP is not a fake.

5) we've associated to a CA, but some CA above it is revoked

This is equivalent to case 2.

So, in summary, I think that if the certificate associated to by the
DANE record is revoked, the revocation should be respected. If a CA
above it is revoked, I don't think that should matter. If a CA/EE cert
below it is revoked, normal PKIX processing applies, and DANE isn't even
involved.

-- 
Scott Schmit

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 17 Aug 2011 10:52:15 +0100

> CA cast doubt on the correctness of the EE certificate?

Because DANE is currently trying to be two things.

1) a mechanism for publishing keys
2) a mechanism for enforcing restrictions on CA issue

If a site is using DANE for the second it cannot be assumed that the site is
even aware of the CA cert revocation. Automating the process of
deregistering the revoked certs is certainly going to be difficult. And then
there is the additional complication of DNSSEC caching.

If people want to do 2 then RPs have to perform the full CRL checking.

> consideration advising against it. ;-)

I can't see any chance of DANE being deployed without automation.

A security consideration that requires manual intervention is very costly.

> below it is revoked, normal PKIX processing applies, and DANE isn't even

This comes under the heading changing PKIX semantics.

PKIX is a security infrastructure. I tend to think that is not going to
happen.

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

---

From: Scott Schmit <[email-masked]>
Date: Wed, 17 Aug 2011 10:14:28 -0400

> 2) a mechanism for enforcing restrictions on CA issue
3) a mechanism for authenticating an EE certificate via DNSSEC instead
of/in addition to a CA.

> there is the additional complication of DNSSEC caching.

If they are using DANE for the second, then case 2 doesn't apply (it
would be case 4 instead ["we've associated to a CA, but that CA is
revoked"]).

For case 2/5 [good EE/CA cert with revoked CA], they will find out when
users complain that their non-DANE clients are unable to connect because
of the revoked CA. Since it would be the users of non-DANE clients
complaining, it's obviously not new to DANE, and the problem already
exists now.

Yes, the DNS cache adds latency to fixing things. This can be made less
bad by associating to the key instead of the certificate or avoiding
very long TTLs.

> If people want to do 2 then RPs have to perform the full CRL checking.

If the associated-to CA is what's being revoked, I agree with you. If
it's above that, not so much. See below, under my response to your
statement that this changes PKIX semantics.

> A security consideration that requires manual intervention is very costly.

For the CAs I've looked at, it's expected that the user configure the
certificate-using services themselves, but perhaps for the pricier
certs, CAs offer more services.

The threat model I was thinking about, where I would no longer trust an
EE cert if its CA was compromised, is if the EE allowed the CA to make
CA-initiated changes to the EE's server configurations to replace the EE
certificate whenever the CA felt like it. And yet, the EE doesn't trust
the CA enough to set the DANE record to associate to the CA cert instead
of the EE cert. It just seemed...odd.

I suppose even that would be ok, provided that the EE actually checks
(automated or otherwise) that the subject key in the EE cert actually
matches the public key held by the EE (and any other relevant fields in
the cert that have security implications for the EE) before accepting
the update.

That assumes, of course, that the private key wasn't provided by the CA
as well. If that's the case, the CA is equivalent to the EE, and I
really don't understand why you don't just associate to the CA instead.

> This comes under the heading changing PKIX semantics.

I'm not exactly sure what you mean by "changing PKIX semantics" or at
least, which ones you think this changes.

What I think you're suggesting is that it's one thing for DANE to add
restrictions, but another for DANE to allow things that were previously
not allowed.

Except we are already doing that by allowing the DNSSEC chain of trust
add a trust anchor to the certificate store (for the name in question).
All I'm saying is that there are essentially two entities vouching for
the associated certificate in this case--the DNSSEC tree and the PKIX CA.

There is a big difference between saying "I, the still-valid PKIX CA, no
longer believe that the subject private key is under the control of the
subject" and "I, the PKIX CA, recuse [revoke] myself, so you should no
longer trust any assertions I made about other certs [possibly after X
date?]". We're in agreement on the former, and in the latter case, the
RP would previously have had to distrust the cert (having no other
source of information), but now DNSSEC can vouch for the associated
cert.

I suppose this is a change for CA processing, in that previously they
could revoke a CA and consider all the certs under it revoked as well,
whereas now, to have the same effect, they'd need to revoke all the
certificates. I can see how that's a bad thing for CAs, but I'm not sure
how this is a bad thing for RPs or EEs. This way, everyone knows exactly
which certs are believed to be misissued or entities compromised.

-- 
Scott Schmit