
Comodo fails to check CAA records - hannob
https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg08027.html
======
floatingatoll
Comodo is communicating actively in the bug, in the email discussion, and
proactively CC'd the original reporter on the bug that was filed about this
without being asked to do so.

The general rule in Operations work is tolerance. You don't fire someone for
making a mistake, you fire them for lying about the mistake, for refusing to
avoid mistake-prone behaviors, and other problem of that sort.

Applying that same principle to CA operations, why on earth should Comodo be
"fired" as a CA for this? They're actively working to solve it, they're
responsive, and the agreements they operate under will compel a post-mortem
into existence if only to meet the terms of their next CA audit.

If, after investigation, they are found to be willfully violating policy,
knowingly lying about CAA support, fail to produce an acceptable post-mortem,
and/or fail their next CA audit, then _of course_ they should be at risk of
direct sanctions - not just a verbal reprimand.

So if your initial response to this issue is "Comodo should be fired",
remember that in Operations culture that specific response "X should be fired"
is a _harmful_ response to a zero-day report of an incident, and many
Operations teams would fire anyone who called for a firing in response to a
fresh incident, in order to protect others from that harmful posture.

~~~
tptacek
I would bet money (maybe not a lot of money, but money) that the only outcome
of this is that Comodo ends up within a month being the CA that most reliably
checks CAA records. It would be shocking if Google penalized them for this.

As you say, that's based in part on how they handle it.

~~~
floatingatoll
The thing I'm sad to see is that there's no third-party information stated on
_when_ Comodo's CAA verification started and stopped. When they first
announced CAA support, who tested it? When did it stop working? So I'm hoping
this will come out of the post-mortem and be shared with us all.

~~~
agwa
Comodo is required by Mozilla to publish a public incident report:
[https://wiki.mozilla.org/CA/Responding_To_A_Misissuance](https://wiki.mozilla.org/CA/Responding_To_A_Misissuance)

------
ameliaquining
Worth noting that the rule they broke has only been in effect for three days
([https://cabforum.org/2017/03/08/ballot-187-make-caa-
checking...](https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-
mandatory/)). This might cause the CAB to go a bit easier on them.

~~~
koolba
They also voted "yes" to the proposal and had 6 months to implement it.

~~~
Panino
Exactly. For some contrast: I use tinydns, which doesn't natively support CAA
records. But I wanted them so I read the CAA spec and wrote a little tool to
add support for these records using the generic record format. And I'm not
even a programmer! (I can write a little code, nothing serious, and nobody
would hire me for it.)

And yet with all of Comodo's resources, they couldn't get this done? I can't
take them seriously.

~~~
geofft
I'd assume that Comodo wrote the code, tested the code, deployed the code, and
forgot to flip the switch to actually enable it in production.

------
tptacek
If you're not already familiar with his work, you should know that Hanno Böck
is a machine, and someone worth following. If there's some mistake you can
make with the web PKI that is so stupid nobody would ever bother to check for
it, rest assured that Hanno will eventually check.

~~~
hdhzy
Couldn't agree more, this (among others) was brilliant:
[https://blog.hboeck.de/archives/888-How-I-tricked-
Symantec-w...](https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-
with-a-Fake-Private-Key.html)

~~~
antihero
Oh that's amazing. Imagine if he'd got, say, Google or Facebook's key revoked
and the havoc it would wreak.

------
jf
If this is the first time you've heard of CAA records, note that the "dig"
command isn't yet aware of these records types, so you need to tell it to use
"type257" as the record type:

    
    
        $ dig empty.basic.caatestsuite.com type257
    

More resources here:

[https://support.dnsimple.com/articles/caa-
record/](https://support.dnsimple.com/articles/caa-record/)

[https://caatestsuite.com/](https://caatestsuite.com/)

~~~
hannob
The dig command is totally aware of it if you have updated bind within the
past couple of years.

------
NelsonMinar
Wikipedia has a nice list of previous Comodo malfeasance:
[https://en.wikipedia.org/wiki/Comodo_Group#Controversies](https://en.wikipedia.org/wiki/Comodo_Group#Controversies)

Highlights include allowing fraudulent certs to be issued for Google, Yahoo,
and Mozilla; working with a malware company; and trademark shenanigans with
Let's Encrypt.

~~~
chipperyman573
>working with a malware company

Why is this a bad thing? A cert says "Yes, person x REALLY IS person x, and I
can prove it mathematically." It doesn't say "Person x is trustworthy enough
for me to vouch for them."

~~~
NelsonMinar
Who do you imagine they verified was Person X? More on the malware cert
issuance: [https://blogs.msmvps.com/donna/2009/05/18/microsoft-mvp-
mike...](https://blogs.msmvps.com/donna/2009/05/18/microsoft-mvp-mike-burgess-
respond-to-comodo-s-ceo-on-comodo-certificates-issued-to-malware-
distributors/)

For malware concerns there's also Comodo's relationship with PrivDog. I'm not
clear on whether PrivDog is deliberate malware or just incompetent insecure
software.

~~~
cortesoft
That is ridiculous, to expect a CA to google every cert request domain and
check what they are doing? That is a ridiculous requirement - cert issuance is
automatic.

Do you think we should stop allowing Let's Encrypt to issue certs? You know
they don't google each domain to see what they are doing.

~~~
pitaj
In my opinion, it would be worse if they denied certs to certain people.

------
Mojah
Curious to see how the CAB will handle this or if they're going to be "soft"
as it's the first days of the CAA enforcement. Historically, they've been very
accurate in enforcing their rules, which could mean a serious reprimand of
Comodo.

If anyone is interested in testing their own CAA records, we built an online
CAA validator specifically for this; [https://dnsspy.io/labs/caa-
validator](https://dnsspy.io/labs/caa-validator)

~~~
michaelt
Between their decision to release a rebranded "more secure" version of Chrome
where their changes had introduced security holes, and their decision to try
and trademark "Let's Encrypt", I can't imagine they have many friends in the
CAB.

On the other hand, they issue a lot of certs - if you've used Cloudflare's
free SSL stuff, you've got a Comodo certificate - so they're unlikely to be
shut down or anything that extreme.

~~~
gsnedders
> On the other hand, they issue a lot of certs - if you've used Cloudflare's
> free SSL stuff, you've got a Comodo certificate - so they're unlikely to be
> shut down or anything that extreme.

They're still smaller than Symantec, for whom the nuclear option was
considered (and ultimately decided against, in favour of a phased
distrusting).

------
PappaPatat
CAA is fresh like IPv10. Done some tracking the last couple of months on the
alexa top 1 million domains. In April 400(!) had CAA records. In August 800.
10% have errors (the issuer-critical flag's value is set to 128, 4 6 or 9)
where it should be either 0 or 1. iodef set to totally unusable web addressed,
you name it. As a matter of fact there are MANY large DNS service providers
that do not even bother providing CAA options. If you want to name and shame,
there is ample opportunity for the years to come. Getting it up and running is
harder but more rewarding in the end.

~~~
aaronmdjones
> 10% have errors (the issuer-critical flag's value is set to 128, 4 6 or 9)
> where it should be either 0 or 1.

Are you certain?

[https://datatracker.ietf.org/doc/rfc6844/?include_text=1](https://datatracker.ietf.org/doc/rfc6844/?include_text=1)

> The data fields are defined as follows:

>

> Flags: One octet containing the following fields:

>

> Bit 0, Issuer Critical Flag: If the value is set to '1', the

> critical flag is asserted and the property MUST be understood

> if the CAA record is to be correctly processed by a certificate

> issuer.

>

> A Certification Authority MUST NOT issue certificates for any

> Domain that contains a CAA critical property for an unknown or

> unsupported property tag that for which the issuer critical

> flag is set.

>

> Note that according to the conventions set out in [RFC1035], bit 0

> is the Most Significant Bit and bit 7 is the Least Significant

> Bit. Thus, the Flags value 1 means that bit 7 is set while a value

> of 128 means that bit 0 is set according to this convention.

EDIT: Fixed formatting? I hope.

------
zero_one_one
That's quite incredible... It'd be interesting to see how up to date the CRL
is as well.

------
twothamendment
This inspired me to add a CAA record for my domain - but
[https://www.namecheap.com](https://www.namecheap.com) doesn't support that
record type. Has anyone had better luck other places?

~~~
agwa
You may find my CAA website helpful:
[https://sslmate.com/caa/support](https://sslmate.com/caa/support)

~~~
twothamendment
I used your site - it was quick and easy. It soon went downhill from there. I
don't run my own DNS or I'd be done pasting the line into my config. Instead I
ran into a UI that doesn't support CAA as a type.

~~~
agwa
Unfortunately, if you want to use CAA your provider must support it. I
recommend you use one of the DNS providers on the page I linked - there are
quite a few to choose from.

------
tehlike
maybe time to revoke Comodo's CA authority. Similar to what has happened
before with Symantec (?).

~~~
scaryclam
Revocation for being three days late in implementing a new standard would be a
massive overreaction. It would harm thousands of businesses in the process and
would be extremely petty. Symantecs misdeeds are _far_ worse than this.

~~~
wbl
Revocation can be done only for new certs. It's time to throw a CA to the dogs
once in a while pour encourage les autres.

~~~
daenney
Not at all. Revoke trust in the signing authority and all it's certificates
turn invalid the second that change hits. Update your OS's trust store to not
trust Comodo anymore and you'll see the effects immediately in IE/Edge on
Windows or Safari and Chrome on macOS (Firefox still ships its own CA bundle).

It's just that when trust has been revoked in CAs recently, it's been done in
a more gradual fashion to not hurt customers too much and give them time to
migrate. After all, it's not the customer's fault the CA went rogue. This
usually starts with not accepting certificates past a certain date but still
validating previously issued ones, until sometime 6 months to a year later
they're completely distrusted.

~~~
wbl
Which is exactly what I said above could be done.

~~~
daenney
That's not at all what you said. What I replied to is where you literally
said:

> Revocation can be done only for new certs.

That's not true. The "newness" of a cert or a CA has absolutely nothing to do
with how, if and when it can be revoked.

------
naraniano
Is it expected from all CAs that they obey CAA records, or is it something
just made up by the community to crush the big CAs? I see an RFC from just a
few years ago, and I'm not sure how these things are standardised.

~~~
owenmarshall
Standardization goes through the CA/B forum. There was a ballot voted to make
CAA checking mandatory for CAs[1], and COMODO voted yes for it.

Any CA that issues certificates publicly need to check CAA from the 8th of
September onward.

[1] [https://cabforum.org/2017/03/08/ballot-187-make-caa-
checking...](https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-
mandatory/)

~~~
naraniano
Ah, so they are three days late. That doesn't sound too serious.

~~~
tinus_hn
On a requirement they voted for half a year ago for a standard specified 5
years ago. It's sloppy and sloppy is not a property you want in a certificate
authority.

~~~
Kalium
From experience working with them, sloppy is an excellent way to describe
Comodo.

