Subject: [dane] CAA: Isn't this completely backwards?

From: Peter Gutmann <[email-masked]>
Date: Tue, 31 May 2011 00:48:26 +1200

I had this queued up for posting a while back but it was the middle of the
Comodo brouhaha so I thought it'd get lost in the noise, hopefully it's not
too stale:

When I first heard of CAA I thought it was great, a web site owner could
indicate that only certificates from CA X should be trusted for their site:

  The Certification Authority Authorization (CAA) DNS Resource Record allows a
  DNS domain name holder to specify the certificate signing certificate(s)
  authorized to issue certificates for that domain.

So to take a random fictitious example, if say a student in Iran got a CA to
issue a cert saying they were Yahoo then the CAA entry in the DNS would
indicate that only Digicert could issue a cert for Yahoo and it'd be rejected
by the browser.

Then I saw things like:

  Thus Relying Applications MUST NOT use failure to conform to currently
  published CAA records as a rejection criteria for certificates unless [...]

OK, so that's not a good start.  What's the intended use for this then?  Let's
see...

  Examples of Use.
  
  The following example informs CAs that certificates must not be issued
  except under [...]

  [DNS entry example]

So the problem we have is that negligent CAs are issuing certs for domains
that they shouldn't be.  In other words we're trying to address the issue of
CA negligence.  The CAA "solution" though is even more prone to failure due to
CA negligence then the existing way of doing things, if one single CA omits to
check the CAA record then they'll go ahead and issue certs contrary to the CAA
policy.

So CAA seems to be operating in a completely backwards manner, instead of
being a whitelist that relies only on the domain holder for security, it's a
blacklist that replies on every single CA capable of issuing a cert to act
diligently, the exact problem that (presumably) motivated CAA in the first
place.

(I know that CAA has all sorts of options to enable all sorts of things, I'm
talking about the default, must-implement mode of operation here).

What's wrong with a simple "hash-of-issuer-name" in the DNS?  That's all it
needs because you've now diversified your risk, the attacker has to compromise
both the CA and the registrar for their attack to succeed.

Peter.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 30 May 2011 13:04:46 +0000

* Peter Gutmann:

> What's wrong with a simple "hash-of-issuer-name" in the DNS?

I think the attacker could still create a malicious sub-CA with the
expected issuer name.  Hashing the whole set of certificates delivered
over TLS would probably work, but this ties your DNS pretty closely to
what your TLS servers are doing.

Relying on CAA to check the CA certificate, in turn, does not work
because issuer DNs are not validated by the current browser PKI and are
mostly garbage.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 31 May 2011 01:19:41 +1200

Florian Weimer <[email-masked]> writes:
>I think the attacker could still create a malicious sub-CA with the expected
>issuer name.

Sure, but this isn't meant to be a buletproof solution, just something to make
an attacker's job a bit harder than the current method of going to a CA and
saying "gimme a cert".  All you have to do is make it at least as secure as
the current weakest link, which is forging a request to the registrar to
change the DNS entry (and that's a pretty low barrier for your $9.95
registrar).

Peter.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 30 May 2011 19:26:55 -0400

Peter,

The problem is that for the larger sites it is not that easy to determine
how many Web servers are in the domain in the first place.

Thus it is necessary to allow the publisher of the CAA record to work in
stages IF NECESSARY. First shutting down issue by non-authorized CAs, then
after assuring themselves that there will be no unanticipated effects
publishing records that enable client enforcement.

If you have a small site with a handful of servers then you can go straight
from issue restrictions to relying application restrictions.

But its still not quite a direct mapping because the information needed for
relying party applications has to be actionable without additional out of
context information. So for that approach you really need to be using the
path directive rather than the policy directive.

And if the issuing side of the scheme is working, you should not need the
client enforcement at all. As with DNSSEC any failure to validate is going
to be much more likely to be the result of misconfiguration than an attack.
So planning a response is quite difficult.

On Mon, May 30, 2011 at 8:48 AM, Peter Gutmann <[email-masked]>wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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