
CAA checking becomes mandatory for SSL/TLS certificates - Mojah
https://ma.ttias.be/caa-checking-becomes-mandatory-ssltls-certificates/
======
klodolph
I think people in here are misunderstanding the threat model this is
protecting against, which is probably because the article doesn't really
explain it.

This is not to protect against malicious CAs. You'd need DNSSEC for that, but
that's just pushing the job down to the next turtle below you, since DNSSEC
needs certificates and trust too.

This is to protect against malicious operators from getting CAs to give them
certificates without authorization of the domain owner. The reason this is
necessary is because the method that CAs use to validate that they're issuing
the certificate to the right person is not standardized, and so you end up
with a bunch of potential ways that an operator could fraudulently get a
certificate that are hard to stop. I know in the past, some CAs would issue to
certificates to anyone with root@, admin@, or any one of a list of privileged
email addresses. Do you want email admins to be able to create whatever
certificates they want for your domain? No.

~~~
discreditable
> This is to protect against malicious operators from getting CAs to give them
> certificates without authorization of the domain owner. The reason this is
> necessary is because the method that CAs use to validate that they're
> issuing the certificate to the right person is not standardized, and so you
> end up with a bunch of potential ways that an operator could fraudulently
> get a certificate that are hard to stop. I know in the past, some CAs would
> issue to certificates to anyone with root@, admin@, or any one of a list of
> privileged email addresses. Do you want email admins to be able to create
> whatever certificates they want for your domain? No.

I don't see how CAA protects against this. If you're using CAA, presumably
your email admin could just request a certificate from one of the whitelisted
CAs. The only saving factor is if your whitelisted CAs don't support email-
based verification.

~~~
tialaramex
There is at least one CA that simply doesn't offer DV. So if you happen to
agree with them that DV is worthless (for the record I do not), or at least
that it's never appropriate for your business, then setting CAA to require
that CA means nobody will be using some scheme to get "legitimate" DV
certificates for your domain.

------
jpalomaki
If I understand correctly, you could set this to 'CAA 0 issue "example.org"'
effectively preventing conforming CAs from issuing certificates for your
domain. Then if you actually need to get a new cert for the domain, you would
temporarily switch the value to your certificate provider of choice.

~~~
mnordhoff
The standard way to do that is:

    
    
        example.com. CAA 0 issue ";"
    

[https://tools.ietf.org/html/rfc6844#section-5.2](https://tools.ietf.org/html/rfc6844#section-5.2)

------
kelnage
...in September 2017, according to the linked article. Title might need a
little tweak to reflect that fact.

------
educar
Last I checked route 53 did not support caa records yet. Any idea when they
might be a available?

------
okket
See also this great gist on CAA adoption:

[https://gist.github.com/roycewilliams/1710ade469c05eb0b090d2...](https://gist.github.com/roycewilliams/1710ade469c05eb0b090d268470aa741)

There was a little discussion on this topic yesterday:

[https://news.ycombinator.com/item?id=14068901](https://news.ycombinator.com/item?id=14068901)
(12 comments)

------
tallanvor
There seem to be very little benefit to this new validation check. The CAs
I've used have required you to prove you have control over the domain you want
a certificate for (either by adding a DNS entry or by responding to an email
sent to one of the defined contacts in the registry.

If someone can already create a new DNS entry for you, they can create their
own CAA entry. If someone has compromised your registry account, they can
always redirect DNS requests for your site to a new location.

~~~
koolba
You have it backwards. The point of this is so that a CA does not issue a
certificate to someone who does not have control of your DNS records. It's a
fail safe.

Plus combining this with Certificate Transparency should allow for handling
this in an automated fashion. A third party can validate CAs to ensure
compliance.

~~~
michaelt

      A third party can validate CAs to ensure compliance.
    

Domain owners can remove or change the CAA record after the certificate has
been issued - so any third parties performing checking will have to be quick
about it :)

~~~
okket
Why would they? The idea of CAA is to help the domain owner, to prevent
malicious issued certificates, to have a documented, open, visible way do
identify which CA is authorised to issue a certificate. So, if you doubt what
you see is legitimate, you have a way to check (also, when combined with
DNSSEC, it is quite hard to forge/spoof).

Even without DNSSEC, every little bit of additional validation counts IMHO.
You could e.g. trace sudden changes in CAA records and get very suspicious...

~~~
tptacek
It's quite hard to forge or spoof to anyone except:

* The world governments that control the TLDs and can thus override DNSSEC policy by fiat.

* Any attacker between the CA's resolver and the DNS server, since DNSSEC only protects transations between DNS servers, not between clients and servers.

~~~
mnordhoff
I would _hope_ CAs run their own DNSSEC validating resolvers, and they don't
just plug "nameserver 8.8.8.8" into resolv.conf.

------
discreditable
What does CAA protect against? Malicious/pwned CAs can issue certificates
anyways. Unless browsers start enforcing CAA correctness, this doesn't seem to
be very useful. Browsers checking the CAA record seems like it would be an
OCSP-like situation where browsers don't do the check to avoid a performance
penalty, or softfail when they get no response.

~~~
tialaramex
Take Facebook's experience last year as an example

Facebook has this policy where all the facebook.com and fb.com certificates,
including sub-domains, test sites, everything, have to go through a central
security team. Obviously they can't reach out to every CA in the world and
tell them about this policy and the millions like it at every company. So they
came to agreement with a single CA, and only ever use that one CA who knows
their rules.

A company working with Facebook built some site, let's call it example.fb.com.
They were responsible for it, so they controlled the content on the site. Some
employee at the contractor wanted an SSL certificate, they'd heard of Let's
Encrypt, so they just used Let's Encrypt to get themselves a certificate.
Let's Encrypt checked their proof of control, it was fine, so it issued a
certificate to the employee.

Now, within 24hours that certificate was published to the Certificate
Transparency system, and Facebook's security team monitors CT, so they saw
there's this certificate for example.fb.com which is from this new Let's
Encrypt service not their usual CA and they didn't ask for it. They,
understandably, go straight to alert status - possible attack in progress.

In that particular case it ends happily, the firm making example.fb.com
confesses to what happened, that they didn't read the terms telling them to
get certificates from Facebook security, the certificates are revoked, it's
not Let's Encrypt's fault this happened, CT logs are proved to do the intended
job...

But CAA allows Facebook to tell everybody "Digicert is the only CA we want
issuing for our names" and not have this whole panic in the first place. With
CAA in place, Let's Encrypt would have told that employee "Issuing for this
name is forbidden due to CAA" and then the employee would look that up on
Google, realise they just violated Facebook's policy and reach out to Facebook
Security. No sirens, maybe somebody gets a slap on the wrist, life goes on.

------
homero
Cloudflare hasn't even mentioned adding that record type

~~~
jgrahamc
We are doing it right now.

------
davidgerard
So only CAs check this, not browsers?

Surely the problem this sort of thing is meant to address is rogue CAs who are
already behaving badly.

~~~
pfg
That's correct. Browsers offer other mechanisms like HPKP to mitigate attacks
through rogue CAs.

Active CAA checks by browsers would either be soft-fail like OCSP (i.e.
useless in the face of an active adversary who could block the request or
spoof the response) or cause a lot of unnecessary warnings because of failed
requests. You'd also have to force every site on earth to create a CAA record
if you want it to be hard-fail. That's going to be impossible.

------
methou
But CAA is fully dependent on DNS(Sec).

~~~
koolba
Why would that be the case? Can't I have untrusted records indicating you _can
't_ do something (issue a cert for a domain)? That's how SPF / DKIM works.

At worst you'd get false rejections which you'd follow up on immediately as
your cert wouldn't be issued.

------
devoply
Sort of an idiotic way to do this considering you can use the DNS
infrastructure to validate the actual certificate and get rid of CAAs
altogether. Chain of trust then goes from the owner of the website directly to
his or her readers rather than some private organization which by its very
nature is already compromised to third parties like the government.

------
pilif
Thankfully, you're still allowed to not have any CAA record for a domain.
While I agree that in general it's a good thing, for my setup, the additional
security it provides is not worth the hassle of upgrading PowerDNS past what
comes with the OS (Debian 8 ships with 3.4.1, CAA requires 4.0.0).

Generally, I notice that the pace of standards requiring newer versions of
software than what's shipping with the latest OS releases is increasingly
quicker these days.

Like ALPN being required for HTTP/2 and not being supported by the latest
stable version of Debian.

