Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Anomalous Certificate Issuances based on historic CAA records

602 views
Skip to first unread message

Quirin Scheitle

unread,
Nov 22, 2017, 6:51:00 PM11/22/17
to mozilla-dev-s...@lists.mozilla.org, sp...@ietf.org, pub...@cabforum.org
/* posting for primary discussion at Mozilla Dev Security Policy, copying CAB Public ML and SPASM@IETF */

Hi all,

the CAA RFC includes an “evaluator” role, a third party than can use public DNS records and
public certificates to surface anomalies in the issuance process.

We have taken this role and analysed a set of certificates for a number of domains for which
we happen to have measured CAA records *at issuance time*.

We would like to share our results here for public discussion.
We believe that this might help to further shape said “evaluator role”.
(In which context and format should findings be shared? What level of detail and assurance is expected?).

Furthermore, our results have surfaced some anomalies that might hint at underlying issues
with CAA validation. We believe that uncovering and discussing unclear cases will help
to sharpen our understanding as a community on how certain cases should be handled.

In that light, I want to share the details of our scan below.

We have found 18 anomalous certificates that can be assigned to 4 groups of possible root causes:

1) Mix of wildcard and non-wildcard DNS names in SAN
Batch: https://misissued.com/batch/32/
Description: best confer https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ

2) Cloudflare FreeSSL certificates issued by Comodo
Batch: https://misissued.com/batch/30/
Description: We are not aware that Cloudflare and Comodo are affiliated, or that Comodo runs
the DNS infrastructure of Cloudflare customers — so these certificates should be checked like any other?

3) Comodo not checking CAA records until Sep 12 [https://bugzilla.mozilla.org/show_bug.cgi?id=1398545]
Batch: https://misissued.com/batch/29/
Description: Comodo did not validate CAA records in the early days, and the certificates in this
batch might have been issued due to this anomaly.

4) Apparent non-evaluation of CAA records
Batch: https://misissued.com/batch/33/
Description: These cases appear as pretty straight-forward that they should not have been issued, but
there might be good explanations


Please note that these categories may overlap. Please find the details below.

To proceed with this as a community, I guess answers to the the following questions from the affected CAs [1] would be of interest:
a) Was CAA checking bypassed for this issuance? If so, why?
b) If CAA lookups were conducted, what response did you receive? Why did it permit issuance?


[1] Thawte, Comodo, Certum,Camerfirma, GlobalSign

I am also happy to file BugZilla bugs if desired.

Kind regards
Quirin

======== Certificate 1 - Group 1 ========
https://crt.sh/?id=215028491
X509v3 Subject Alternative Name:
DNS:*.netservicesgroup.com
DNS:netservicesgroup.com
Issuer COMODO CA Limited
DNS history (Certificate issued on Sep 20):
2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-18:netservicesgroup.com. 86400 IN CAA 0 issue ";"
2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-19:netservicesgroup.com. 86400 IN CAA 0 issue ";"
2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-20:netservicesgroup.com. 86400 IN CAA 0 issue “;"
2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issuewild "comodoca.com"
2017-09-21:netservicesgroup.com. 86400 IN CAA 0 issue ";"
2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issuewild “comodoca.com"
2017-09-23:netservicesgroup.com. 86400 IN CAA 0 issue “;"

======== Certificate 2 - Group 1 =======
https://crt.sh/?id=211113116
X509v3 Subject Alternative Name:
DNS:*.trnava-vuc.sk
DNS:trnava-vuc.sk
Issuer: thawte, Inc.
DNS history (Certificate issued on Sep 13)
2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issuewild "symantec.com"
2017-09-11:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issuewild "thawte.com"
2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issue ";"
2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-15:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-16:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-17:trnava-vuc.sk. 86400 IN CAA 0 issue ";"

======== Certificate 3 - Group 1 ========
https://crt.sh/?id=226175601
X509v3 Subject Alternative Name:
DNS:*.drillisch-online.de
DNS:drillisch-online.de
Issuer: COMODO CA Limited
DNS history (Certificate issued on Sep 29):
2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "globalsign.com"
2017-09-28:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
2017-09-28:drillisch-online.de. 3600 IN CAA 0 issue ";"
2017-09-29:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
2017-09-29:drillisch-online.de. 3600 IN CAA 0 issue ";"
2017-09-30:drillisch-online.de. 3600 IN CAA 0 issuewild "comodoca.com"
2017-09-30:drillisch-online.de. 3600 IN CAA 0 issue ";"

======= Certificate 4 - Group 1 =======
https://crt.sh/?id=221763552
X509v3 Subject Alternative Name:
DNS:*.uhlhosting.ch
DNS:uhlhosting.ch
Issuer: Comodo
DNS history (Certificate issued on Sep 29):
2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com"
2017-09-27: uhlhosting.ch. 14400 IN CAA 0 issue “;”
2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com”
2017-09-28: uhlhosting.ch. 14400 IN CAA 0 issue “;”
2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com”
2017-09-29: uhlhosting.ch. 14400 IN CAA 0 issue “;”
2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issuewild “comodoca.com"
2017-09-30: uhlhosting.ch. 14400 IN CAA 0 issue “;”

======== Certificate 5 - Group 1 ========
https://crt.sh/?id=211729608
X509v3 Subject Alternative Name:
DNS:*.provida.net
DNS:provida.net
Issuer: COMODO CA Limited
DNS history (Certificate issued on Sep 15):
2017-09-13:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-13:provida.net. 600 IN CAA 0 issuewild "symantec.com"
2017-09-13:provida.net. 600 IN CAA 0 issue ";"
2017-09-14:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-14:provida.net. 600 IN CAA 0 issuewild “symantec.com"
2017-09-14:provida.net. 600 IN CAA 0 issue “;"
2017-09-15:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-15:provida.net. 600 IN CAA 0 issuewild "symantec.com"
2017-09-15:provida.net. 600 IN CAA 0 issue ";"
2017-09-16:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-16:provida.net. 600 IN CAA 0 issuewild “symantec.com"
2017-09-16:provida.net. 600 IN CAA 0 issue “;"
2017-09-17:provida.net. 600 IN CAA 0 issuewild "comodo.com"
2017-09-17:provida.net. 600 IN CAA 0 issuewild "symantec.com"
2017-09-17:provida.net. 600 IN CAA 0 issue “;”

======= Certificate 6 - Group 1 =======
https://crt.sh/?id=223356078
X509v3 Subject Alternative Name:
DNS:*.cyberbajt.pl
DNS:cyberbajt.pl
Issuer: Unizeto Technologies S.A. (-> Certum)
DNS history (Certificate issued on Oct 1):
2017-09-27:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-09-27:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-09-28:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-09-28:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-09-29:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-09-29:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-09-30:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-09-30:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-10-01:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-10-01:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-10-02:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-10-02:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-10-03:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-10-03:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"
2017-10-04:cyberbajt.pl. 86400 IN CAA 0 issue ";"
2017-10-04:cyberbajt.pl. 86400 IN CAA 0 issuewild "certum.pl"

======= Certificate 7 - Group 1 ======
https://crt.sh/?id=250171539
X509v3 Subject Alternative Name:
DNS:*.s5.nl
DNS:s5.nl
Issuer: Comodo
DNS history (Issued Nov 06):
2017-11-03:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-03:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"
2017-11-04:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-04:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"
2017-11-05:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"
2017-11-05:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-06:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"
2017-11-06:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-07:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"
2017-11-07:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-08:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-08:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"
2017-11-09:s5.nl. 3600 IN CAA 0 issue "letsencrypt.org"
2017-11-09:s5.nl. 3600 IN CAA 0 issuewild "comodoca.com"


======= Certificate 8 - Group 1 ======
https://crt.sh/?id=254174871
X509v3 Subject Alternative Name:
DNS:*.invinsec.com
DNS:invinsec.com
Issuer: GlobalSign (AlphaSSL)
DNS history (Issued Nov 12 00:57):
2017-11-10:invinsec.com. 300 IN CAA 0 issue "digicert.com"
2017-11-10:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org"
2017-11-10:invinsec.com. 300 IN CAA 0 issuewild ";"
2017-11-11:invinsec.com. 300 IN CAA 0 issue "digicert.com"
2017-11-11:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org"
2017-11-11:invinsec.com. 300 IN CAA 0 issuewild "globalsign.com"
2017-11-12:invinsec.com. 300 IN CAA 0 issue "digicert.com"
2017-11-12:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org"
2017-11-12:invinsec.com. 300 IN CAA 0 issuewild "globalsign.com"
2017-11-13:invinsec.com. 300 IN CAA 0 issue "digicert.com"
2017-11-13:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org"
2017-11-13:invinsec.com. 300 IN CAA 0 issuewild "globalsign.com"
2017-11-14:invinsec.com. 300 IN CAA 0 issue "digicert.com"
2017-11-14:invinsec.com. 300 IN CAA 0 issue "letsencrypt.org"
2017-11-14:invinsec.com. 300 IN CAA 0 issuewild “globalsign.com"

======= Certificate 9 - Group 1 ======
https://crt.sh/?id=261922875
X509v3 Subject Alternative Name:
DNS:*.imagindata.com
DNS:imagindata.com
Issuer: Comodo
DNS history (Issued Oct 14):
2017-10-12:imagindata.com. 300 IN CAA 0 issue “;"
2017-10-12:imagindata.com. 300 IN CAA 0 issuewild “comodoca.com
2017-10-13:imagindata.com. 300 IN CAA 0 issue “;"
2017-10-13:imagindata.com. 300 IN CAA 0 issuewild “comodoca.com
2017-10-14:imagindata.com. 300 IN CAA 0 issue “;"
2017-10-14:imagindata.com. 300 IN CAA 0 issuewild “comodoca.com
2017-10-15:imagindata.com. 300 IN CAA 0 issue “;"
2017-10-15:imagindata.com. 300 IN CAA 0 issuewild “comodoca.com
2017-10-16:imagindata.com. 300 IN CAA 0 issue “;"
2017-10-16:imagindata.com. 300 IN CAA 0 issuewild “comodoca.com

====== Certificate 10 - Group 1 =========
https://crt.sh/?id=235359928
X509v3 Subject Alternative Name:
DNS:*.gbase.com
DNS:gbase.com
Issuer: Comodo
DNS history (Issued Oct 17):
2017-10-15:gbase.com. 432000 IN CAA 0 issue ";"
2017-10-15:gbase.com. 432000 IN CAA 0 issuewild "comodoca.com"
2017-10-16:gbase.com. 432000 IN CAA 0 issue ";"
2017-10-16:gbase.com. 432000 IN CAA 0 issuewild “comodoca.com"
2017-10-17:gbase.com. 432000 IN CAA 0 issue ";"
2017-10-17:gbase.com. 432000 IN CAA 0 issuewild “comodoca.com"
2017-10-18:gbase.com. 432000 IN CAA 0 issue ";"
2017-10-18:gbase.com. 432000 IN CAA 0 issuewild “comodoca.com"
2017-10-19:gbase.com. 432000 IN CAA 0 issue ";"
2017-10-19:gbase.com. 432000 IN CAA 0 issuewild “comodoca.com”


======= Certificate 11 - Group 2, Group 3 =======
https://crt.sh/?id=206166802
X509v3 Subject Alternative Name:
DNS:sni242586.cloudflaressl.com
… (way more DNS names...)
DNS:reed.systems
DNS:*.reed.systems
… (way more DNS names…)
Issuer: Comodo
DNS history (Certificate issued on Sep 8):
2017-09-03:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-04:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-05:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-06:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-07:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-08:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-09:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-10:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-11:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-12:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-13:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-14:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-15:reed.systems. 300 IN CAA 0 issue "letsencrypt.org"

======= Certificate 12, Group 2, Group 3 ======
https://crt.sh/?id=207953208
X509v3 Subject Alternative Name:
DNS:sni89771.cloudflaressl.com
… (way more DNS names…)
DNS:*.ficud.international
DNS:ficud.international
DNS:*ficud.academy
DNS:ficud.academy
DNS:*ficud.info
DNS:ficud.info
… (way more DNS names…)
Issuer: Comodo
DNS history (Certificate issued on Sep 12):
2017-09-06:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-06:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-07:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-07:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-08:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-08:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-09:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-09:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-10:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-10:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-11:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-11:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-12:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-12:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-13:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-13:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-14:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-14:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-15:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-15:ficud.international. 300 IN CAA 0 issue "symantec.com"
2017-09-16:ficud.international. 300 IN CAA 0 issue "letsencrypt.org"
2017-09-16:ficud.international. 300 IN CAA 0 issue "symantec.com"

ficud.academy and ficud.info have the same DNS history.


======= Certificate 13 - Group 3 ========
https://crt.sh/?id=246909989
X509v3 Subject Alternative Name:
DNS:southcentralcompany-rewards.com
…
Issuer: cPanel (-> Comodo)
DNS history (Certificate issued on Sep 10):
2017-09-05:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-06:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-07:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-08:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-09:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-10:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-11:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-12:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-13:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-14:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-15:southcentralcompany-rewards.com. 60 IN CAA 0 issue "symantec.com"


======== Certificate 14 - Group 3 =======
https://crt.sh/?id=261112312
X509v3 Subject Alternative Name:
DNS:southcentralcompany-rewards.com
...
Issuer: cPanel (-> Comodo)
DNS history (Certificate issued on Sep 10):
2017-09-05:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-06:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-07:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-08:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-09:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-10:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-11:homeinsteadrewards.com. 59 IN CAA 0 issue "symantec.com"
2017-09-12:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-13:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-14:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"
2017-09-15:homeinsteadrewards.com. 60 IN CAA 0 issue "symantec.com"


====== Certificate 15 - Group 3 ======
(Please note this was issued past Sep 12)
https://crt.sh/?id=211648524
X509v3 Subject Alternative Name:
DNS:www.panphuree.com
DNS:panphuree.com
Issuer: Comodo
DNS history (Certificate issued on Sep 14):
2017-09-12:panphuree.com. 14400 IN CAA 0 issue ";"
2017-09-13:panphuree.com. 14400 IN CAA 0 issue ";"
2017-09-14:panphuree.com. 14400 IN CAA 0 issue ";"
2017-09-15:panphuree.com. 14368 IN CAA 0 issue ";"
2017-09-16:panphuree.com. 14400 IN CAA 0 issue ";"
2017-09-17:panphuree.com. 14400 IN CAA 0 issue ";"
2017-09-18:panphuree.com. 14400 IN CAA 0 issue ";"

======= Certificate 16 - Group 4 =======
https://crt.sh/?id=257856701
X509v3 Subject Alternative Name:
...
DNS:am-hosting.de
DNS:www.am-hosting.de
DNS:*.am-hosting.de
…
Issuer: AC CAMERFIRMA
DNS history (Issued: Nov 16 14:28 GMT)
2017-11-12:am-hosting.de. 43200 IN CAA 0 issue "letsencrypt.org"
2017-11-13:am-hosting.de. 43200 IN CAA 0 issue "letsencrypt.org"
2017-11-14:am-hosting.de. 43200 IN CAA 0 issue "letsencrypt.org"
2017-11-15:am-hosting.de. 43200 IN CAA 0 issue "letsencrypt.org"
2017-11-16:am-hosting.de. 43200 IN CAA 0 issue "letsencrypt.org"
2017-11-17:am-hosting.de. 43200 IN CAA 0 issue "letsencrypt.org"
2017-11-18:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”

Zoomed (UTC timestamps)
2017-11-15-18:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-15-22:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-15-02:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-16-06:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-16-10:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-16-14:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
Issued: Nov 16 14:28 GMT
2017-11-16-18:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-16-22:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-17-02:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”
2017-11-17-06:00:am-hosting.de. 43200 IN CAA 0 issue “letsencrypt.org”


======= Certificate 17 - Group 4 =======
https://crt.sh/?id=255113449
X509v3 Subject Alternative Name:
DNS:*.bankvrn.ru
DNS:bankvrn.ru
Issuer: Comodo
DNS history(Issued Sep 28)
2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "geotrust.com"
2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "letsencrypt.org"
2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "thawte.com"
2017-09-27:bankvrn.ru. 3600 IN CAA 0 issue "wosign.com"
2017-09-27:bankvrn.ru. 3600 IN CAA 0 issuewild “;"
2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue "letsencrypt.org"
2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue "wosign.com"
2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue "thawte.com"
2017-09-28:bankvrn.ru. 3600 IN CAA 0 issue “geotrust.com"
2017-09-28:bankvrn.ru. 3600 IN CAA 0 issuewild ";"
2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "thawte.com"
2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "letsencrypt.org"
2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "geotrust.com"
2017-09-29:bankvrn.ru. 3600 IN CAA 0 issue "wosign.com"
2017-09-29:bankvrn.ru. 3600 IN CAA 0 issuewild ";"


======== Certificate 18 - Group 4 =======
https://crt.sh/?id=252132456
X509v3 Subject Alternative Name:
DNS:mc21colombia.com
DNS:www.mc21colombia.com
Issuer: cPanel (-> Comodo)
DNS history (Issued Oct 17):
2017-10-14:mc21colombia.com. 3600 IN CAA 0 issuewild "digicert.com"
2017-10-15:mc21colombia.com. 3600 IN CAA 0 issuewild "digicert.com"
2017-10-17:mc21colombia.com. 3600 IN CAA 0 issuewild "digicert.com"
2017-10-18:mc21colombia.com. 300 IN CAA 0 issuewild "digicert.com"
2017-10-18:mc21colombia.com. 300 IN CAA 0 issue "digicert.com"
2017-10-19:mc21colombia.com. 300 IN CAA 0 issue "digicert.com"
2017-10-19:mc21colombia.com. 300 IN CAA 0 issuewild "digicert.com"
2017-10-20:mc21colombia.com. 300 IN CAA 0 issue "digicert.com"
2017-10-20:mc21colombia.com. 300 IN CAA 0 issuewild "digicert.com"
2017-10-21:mc21colombia.com. 300 IN CAA 0 issuewild "digicert.com"
2017-10-21:mc21colombia.com. 300 IN CAA 0 issue "digicert.com"
2017-10-22:mc21colombia.com. 300 IN CAA 0 issuewild "digicert.com"
2017-10-22:mc21colombia.com. 300 IN CAA 0 issue “digicert.com"


—
Quirin Scheitle Web: https://www.net.in.tum.de/~scheitle/
Technische Universität München Room: 03.05.037
Department of Computer Science Tel: +49.89.289.18012
Network Architectures and Services

signature.asc

Nick Lamb

unread,
Nov 23, 2017, 7:24:19 AM11/23/17
to dev-secur...@lists.mozilla.org, Quirin Scheitle
On Thu, 23 Nov 2017 00:50:04 +0100
Quirin Scheitle via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> 2) Cloudflare FreeSSL certificates issued by Comodo
> Batch: https://misissued.com/batch/30/
> Description: We are not aware that Cloudflare and Comodo are
> affiliated, or that Comodo runs the DNS infrastructure of Cloudflare
> customers — so these certificates should be checked like any other?

My understanding is that Cloudflare CDN (usually? always?) is enabled by
giving Cloudflare control over DNS for the names you want given CDN
treatment, either a CNAME or direct name server control.

I assume Comodo's arrangement with Cloudflare to permit bulk issuance
is streamlined significantly by this control over DNS and in exchange
Cloudflare gets a very good deal on those certificates, with the
exact details presumably commercially sensitive. It doesn't seem
unlikely that Comodo skip some checks for names that Cloudflare control
in this way.


It would be concerning if as a result of the streamlining it is /ever/
possible for Cloudflare to obtain certificates for names that were not
actually assigned by the above mechanism to Cloudflare, even if this
only happened accidentally - because responsibility for correct issuance
must lie with Comodo, not Cloudflare, any abdication of decision making
power to an untrusted third party can be a Big Problem, just as
we saw with Symantec.


It would be less concerning, but still problematic if Cloudflare
allowed a situation to exist in which their customers could use
Cloudflare CDN for a name (so Cloudflare would ask Comodo to
issue certificates for this name) while also setting CAA to forbid
issuance by Comodo for the name, and then get a certificate issued
anyway. This is clearly a violation of the rules as written, and
shouldn't happen, but I'd be comfortable seeing this as basically a
goof, a mismatch between intention and implementation, just needing a
software fix and maybe some better documentation from Cloudflare so
that it doesn't happen again.


Can we have a comment from Comodo about this? And if appropriate they
can invite someone technical from Cloudflare to comment too.


Nick.

Han Yuwei

unread,
Nov 23, 2017, 11:33:34 PM11/23/17
to mozilla-dev-s...@lists.mozilla.org
在 2017年11月23日星期四 UTC+8下午8:24:19，Nick Lamb写道：
Comodo will check CAA before issurance even domain in Cloudflare. I asked it before (https://groups.google.com/d/msg/mozilla.dev.security.policy/rFyPQ0o7RMM/bBhqXEV8BQAJ). So I think Comodo should give a comment about this.

Quirin Scheitle

unread,
Nov 24, 2017, 6:23:33 AM11/24/17
to Han Yuwei, mozilla-dev-s...@lists.mozilla.org

> On 24. Nov 2017, at 05:33, Han Yuwei via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Comodo will check CAA before issurance even domain in Cloudflare. I asked it before (https://groups.google.com/d/msg/mozilla.dev.security.policy/rFyPQ0o7RMM/bBhqXEV8BQAJ). So I think Comodo should give a comment about this.

HI Han,

thank you for this pointer, I was not aware of this.
I would conclude that these certificates do not constitute a special case then, and are just a case of "Comodo not checking CAA records until Sep 12”.

Kind regards
Quirin

Rob Stradling

unread,
Nov 24, 2017, 6:35:46 AM11/24/17
to Quirin Scheitle, Han Yuwei, mozilla-dev-s...@lists.mozilla.org
Hi Quirin. That conclusion is correct.

The 2 certs issued to Cloudflare customers that are listed at
https://misissued.com/batch/30/ were issued on September 8th and 11th
2017, which was during the period of time that our CAA implementation
was completely broken. See our earlier incident report [1] for the details.


[1]
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg08054.html

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

Gervase Markham

unread,
Nov 24, 2017, 7:23:25 AM11/24/17
to mozilla-dev-s...@lists.mozilla.org
Hi Quirin,

Thank you for your work on this topic. I would be grateful if you could
file Bugzilla bugs in the Misissuance component as follows, giving your
evidence of misissuance:

On 22/11/17 23:50, Quirin Scheitle wrote:
> 1) Mix of wildcard and non-wildcard DNS names in SAN
> Batch: https://misissued.com/batch/32/
> Description: best confer https://groups.google.com/d/msg/mozilla.dev.security.policy/O9HZPMvHMY8/HtXR8S-1AAAJ

One bug per CA, please.

> 4) Apparent non-evaluation of CAA records
> Batch: https://misissued.com/batch/33/
> Description: These cases appear as pretty straight-forward that they should not have been issued, but
> there might be good explanations

One bug for the two Comodo certs, one for the Camerfirma cert.

Thank you,

Gerv

douglas...@gmail.com

unread,
Nov 29, 2017, 6:26:47 AM11/29/17
to mozilla-dev-s...@lists.mozilla.org
Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com", "globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as “issue” at time of issuance.

Doug

Quirin Scheitle

unread,
Nov 29, 2017, 10:26:40 AM11/29/17
to douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org
Hi Douglas,

thank you for your reply! I have posted a detailed reply at https://bugzilla.mozilla.org/show_bug.cgi?id=1420766

Short version: We measure every 8 hours, and I believe the records you have seen existed for a short time around your issuance lookup.

So this would be a false positive, based on the fact that an evaluator/auditor can only query so often and records may be changed multiple times between two measurements.

Kind regards
Quirin

> On 29. Nov 2017, at 12:26, douglas.beattie--- via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> Hi Quirin,
>
> I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged?
>
> We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded.
>
> We logged that there was no “issuewild” entry and that "digicert.com", "globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as “issue” at time of issuance.
>
> Doug
>
> On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Jeremy Rowley

unread,
Nov 29, 2017, 3:44:45 PM11/29/17
to douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org
The Thawte records aren't showing any CAA record preventing wildcards either.

Here's the Thawte CAA record logs for the domain:

2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500
2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk
2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 5 result: 4 lookupTimeout: 750
2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of trnava-vuc.sk is: 1
2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of *.trnava-vuc.sk is: 2

Jeremy
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of douglas.beattie--- via dev-security-policy
Sent: Wednesday, November 29, 2017 4:27 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com", "globalsign.com", "letsencrypt.org" and "rapidssl.com" are all defined as “issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
>
> Thank you for your work on this topic. I would be grateful if you
> could file Bugzilla bugs in the Misissuance component as follows,
> giving your evidence of misissuance:
>
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > Description: best confer
> > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fgroups.google
> > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > 1AAAJ
>
> One bug per CA, please.
>
> > 4) Apparent non-evaluation of CAA records
> > Batch: https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F33%2F
> > Description: These cases appear as pretty straight-forward that they should not have been issued, but
> > there might be good explanations
>
> One bug for the two Comodo certs, one for the Camerfirma cert.
>
> Thank you,
>
> Gerv

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/oAalxx5y7jnwYJenYD34I2nHx_u_mkjdw0--8ecHQ0s=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

Ben Laurie

unread,
Nov 29, 2017, 5:00:48 PM11/29/17
to Jeremy Rowley, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org
This whole conversation makes me wonder if CAA Transparency should be a
thing.

On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <
> > Hi Quirin,
> >
> > Thank you for your work on this topic. I would be grateful if you
> > could file Bugzilla bugs in the Misissuance component as follows,
> > giving your evidence of misissuance:
> >
> > On 22/11/17 23:50, Quirin Scheitle wrote:
> > > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > > Batch: https://clicktime.symantec.com/a/1/
> 4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_
> 82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_
> 74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-
> IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_
> 4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD
> 8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_
> 01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_
> 6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-
> D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SB
> e&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > > Description: best confer
> > > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fgroups.google
> > > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > > 1AAAJ
> >
> > One bug per CA, please.
> >
> > > 4) Apparent non-evaluation of CAA records
> > > Batch: https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--
> jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-
> CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgt
> uvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0Lh
> TmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__
> 1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHo
> xoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-
> J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4
> WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3C
> iwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.
> com%2Fbatch%2F33%2F
> > > Description: These cases appear as pretty straight-forward that
> they should not have been issued, but
> > > there might be good explanations
> >
> > One bug for the two Comodo certs, one for the Camerfirma cert.
> >
> > Thank you,
> >
> > Gerv
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/oAalxx5y7jnwYJenYD34I2nHx_u_
> mkjdw0--8ecHQ0s=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_
> pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgt
> uvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0Lh
> TmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__
> 1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHo
> xoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-
> J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4
> WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3C
> iwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Flists.
> mozilla.org%2Flistinfo%2Fdev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

Jeremy Rowley

unread,
Nov 29, 2017, 5:23:04 PM11/29/17
to Ben Laurie, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org
Yes, CAA transparency should exist. Right now CAA is only a point-in-time check by the CA with no way to verify what the CA saw or what was processed. This was one of the limitations raised during the discussions about adoption. Without some transparency, the reliance is on the CA to ensure the CAA record checking is properly done and not useful to subscribers. Despite the lack of transparency, CAA checking is still useful as it can help a CA prevent unauthorized issuance, even if the prevention/CAA record check results aren’t publicly available. CAA is a useful tool for CAs but could be a more useful tools for researchers if there was a good way to make the record check results more publicly available.



Jeremy

From: Ben Laurie [mailto:be...@google.com]
Sent: Wednesday, November 29, 2017 3:01 PM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: douglas...@gmail.com; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Anomalous Certificate Issuances based on historic CAA records



This whole conversation makes me wonder if CAA Transparency should be a thing.



On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:

The Thawte records aren't showing any CAA record preventing wildcards either.

Here's the Thawte CAA record logs for the domain:

2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk <http://trnava-vuc.sk> type: 257 result: 4 lookupTimeout: 500
2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk <http://trnava-vuc.sk>
2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk <http://trnava-vuc.sk> type: 5 result: 4 lookupTimeout: 750
2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of trnava-vuc.sk <http://trnava-vuc.sk> is: 1
2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of *.trnava-vuc.sk <http://trnava-vuc.sk> is: 2

Jeremy
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley <mailto:dev-security-policy-bounces%2Bjeremy.rowley> =digice...@lists.mozilla.org <mailto:digice...@lists.mozilla.org> ] On Behalf Of douglas.beattie--- via dev-security-policy
Sent: Wednesday, November 29, 2017 4:27 AM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

Hi Quirin,

I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged?

We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded.

We logged that there was no “issuewild” entry and that "digicert.com <http://digicert.com> ", "globalsign.com <http://globalsign.com> ", "letsencrypt.org <http://letsencrypt.org> " and "rapidssl.com <http://rapidssl.com> " are all defined as “issue” at time of issuance.

Doug

On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote:
> Hi Quirin,
>
> Thank you for your work on this topic. I would be grateful if you
> could file Bugzilla bugs in the Misissuance component as follows,
> giving your evidence of misissuance:
>
> On 22/11/17 23:50, Quirin Scheitle wrote:
> > 1) Mix of wildcard and non-wildcard DNS names in SAN
> > Batch: https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F
> > Description: best confer
> > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx
> > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF
> > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B
> > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA
> > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8
> > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt
> > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh
> > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF
> > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fgroups.google
> > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S-
> > 1AAAJ
>
> One bug per CA, please.
>
> > 4) Apparent non-evaluation of CAA records
> > Batch: https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F33%2F
> > Description: These cases appear as pretty straight-forward that they should not have been issued, but
> > there might be good explanations
>
> One bug for the two Comodo certs, one for the Camerfirma cert.
>
> Thank you,
>
> Gerv

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://clicktime.symantec.com/a/1/oAalxx5y7jnwYJenYD34I2nHx_u_mkjdw0--8ecHQ0s=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy



Paul Wouters

unread,
Nov 29, 2017, 5:34:03 PM11/29/17
to Ben Laurie, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley


> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> This whole conversation makes me wonder if CAA Transparency should be a
> thing.

That is a very hard problem, especially for non-DNSSEC signed ones.

Paul

Ben Laurie

unread,
Nov 29, 2017, 5:37:18 PM11/29/17
to Paul Wouters, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley
Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
chain of responsibility for keys, and that is relatively easy to build on.

Nick Lamb

unread,
Nov 29, 2017, 6:33:15 PM11/29/17
to dev-secur...@lists.mozilla.org
On Wed, 29 Nov 2017 22:37:08 +0000
Ben Laurie via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear
> chain of responsibility for keys, and that is relatively easy to
> build on.

For DNSSEC a CA could (and I would hope that they do) collect enough
records to show that the CAA result they relied on was authentic after
the fact.

It is in the nature of a distributed system like DNS that it would be
possible that this was not the _only_ authentic result available on the
network at the time of issuance, and the CA has no way to know of any
other results that are inconsistent with issuance once they have one
which is consistent.

Of course the existence of contradictory authentic results SHOULD not
be ordinarily the case for a well-managed domain but we know it
happens, and it would be even more likely for test systems although
they should have the know-how to control this.

Quirin Scheitle

unread,
Nov 30, 2017, 4:03:01 AM11/30/17
to Jeremy Rowley, mozilla-dev-s...@lists.mozilla.org
Hi Jeremy,

thank you for sharing that log! The associated bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1420861

I do not know how to parse all the details in the log, but I guess the line

> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]

means that you have seen an NODATA (empty) reply at 2017-09-13 05:25:09 in an unknown(but at this point irrelevant) timezone.
Similar to the GlobalSign discussion, it is well possible that the domain briefly disabled their CAA records when you did the check — and re-enabled them later.
A quirk in the lookup process would probably trigger some kind of timeout/unreachable log.

The consistency displayed in our scans [1] and the fact that this error class (wildcard/non-wildcard) seems to have affected several cases made this case look suspicious, so I had raised it.
I am very happy to accept your reply and classify this as a false positive. I also thinks it is a very positive example that CAs can and do provide log excerpts for such cases.

Regarding the “CAA Transparency” discussion: Yes, I would welcome this and be happy to support designing it.
I do not think it requires DNSSEC, just storing the relevant DNS replies in wire format by the CAs would be a great start.

Kind regards
Quirin

[1]
2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-12:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issuewild "thawte.com"
2017-09-13:trnava-vuc.sk. 86400 IN CAA 0 issue ";"
2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issuewild "thawte.com"
2017-09-14:trnava-vuc.sk. 86360 IN CAA 0 issue ";"


> On 29. Nov 2017, at 21:44, Jeremy Rowley via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> The Thawte records aren't showing any CAA record preventing wildcards either.
>
> Here's the Thawte CAA record logs for the domain:
>
> 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 257 result: 4 lookupTimeout: 500
> 2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk
> 2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk type: 5 result: 4 lookupTimeout: 750
> 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of trnava-vuc.sk is: 1
> 2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ]
> 2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of *.trnava-vuc.sk is: 2

Ryan Sleevi

unread,
Nov 30, 2017, 9:53:14 AM11/30/17
to Quirin Scheitle, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley
On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Similar to the GlobalSign discussion, it is well possible that the domain
> briefly disabled their CAA records when you did the check — and re-enabled
> them later.
>

I think that, as CAA deployment becomes common, this pattern will be
not-uncommon. I would hope we don't sound false alarms when it does.

This is pretty explicitly spelled out in the CAA RFC:
CAA records MAY be used by Certificate Evaluators as a possible
indicator of a security policy violation. Such use SHOULD take
account of the possibility that published CAA records changed between
the time a certificate was issued and the time at which the
certificate was observed by the Certificate Evaluator.

That said, the role of evaluators is less so in reporting to the CAs, but
as noted within the CAA RFC:
iodef <URL> : Specifies a URL to which an issuer MAY report
certificate issue requests that are inconsistent with the issuer's
Certification Practices or Certificate Policy, or that a
Certificate Evaluator may use to report observation of a possible
policy violation. The Incident Object Description Exchange Format
(IODEF) format is used [RFC5070].


This is because the only party who can ascertain intent unambiguously here
is the subscriber. Independent parties such as evaluators lack the context
both from the POV of the Applicant and the CA to identify misissuance, and
unless we (incorrectly, I would argue) want to require that CAA records be
'sticky' and 'globally observed' for some time before issuing a cert, then
this pattern will be a regular part of operation.

For example, an organization that wants to ensure that all certificates are
directed through a central purchasing team would, rather than place the
name of that CA in their CAA record (although they could), potentially
place themselves in their record, and then make the changes whenever they
need to renew, replace, or issue certificates - for the duration of the
issuance request.

I agree that it's early in the CAA deployment story, that we're likely to
see and continue to see bugs as CA's (finally, after years of discussion)
familiarize themselves with it and their implementation, and I agree, it's
unfortunate that some extent of these edge cases are not well tested or
testable. But I'm also wanting to make sure that we don't prematurely
increase the perceived cost of CAA such that it would rightfully make an
argument that the cost outweighs the benefits - from things like false
positive reporting.

Just my $.02

Tim Hollebeek

unread,
Nov 30, 2017, 3:13:41 PM11/30/17
to Ben Laurie, Paul Wouters, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley
So it turns out DNSSEC solves CAA problems for almost nobody, because almost
nobody uses DNSSEC. And given the serious flaws both in DNSSEC itself and
exiting DNSSEC implementations, it is unlikely to be part of any solution to
the current problems CAA is facing. The presence of DNSSEC in the BR policy
for handling DNS failures, in hindsight, was probably a mistake, and
certainly deserved a lot more scrutiny than it got (Gerv tossed it out as a
possible compromise during CABF F2F discussion, and everyone sort of
shrugged and put it in because it seemed reasonable at the time). Right
now, the only thing it is really accomplishing is preventing certificate
issuance to customers whose DNS infrastructure is flaky, misconfigured, or
unreliable. Longer term, DNS over HTTPS is probably a more useful path
forward than DNSSEC for CAA, but unfortunately that is still in it's
infancy.

One of the things that has become very clear over the last year is that the
idea that the idea that there is a single, globally coherent state for what
DNS says at any particular time is more of a myth than a reality. I'm sure
that most people familiar with DNS were already well aware of that, but it
has been entertaining seeing that almost every possible DNS failure mode
happens in practice with disturbing frequency.

The problem DNSSEC checks for CAA was intended to solve was the fact that it
is certainly possible that a well-resourced attacker can manipulate the DNS
responses that the CA sees as part of its CAA checks. A better mitigation,
perhaps, is for multiple parties to publicly attest in a verifiable way as
to what the state of DNS was at/near the time of issuance with respect to
the relevant CAA records. This leads to the idea that perhaps it's worth
exploring enhancing existing CT logging servers to do CAA checks and log
what they see. That's probably easier than setting up an entirely separate
infrastructure for CAA transparency. CT servers could even communicate back
to CAs the results they see to assist in detecting and identifying both
malicious and non-malicious discrepancies between the CA's own checks and
what the CT log is seeing. "Thanks for the pre-cert. We see a CAA record
at X.Y.Z.Z.Y that doesn't include you. Do you really want to issue?" There
are legitimate concerns that giving even more work to CT log servers might
put even more burden and expense onto those who are running CT log servers,
but that can probably be figured out.

Of course, to avoid some of the extremely interesting experiences the
industry has had with CAA, any "improved" version of CAA needs to be much
more clear about the proper handling of error conditions, discrepancies in
DNS responses, handling of malformed CAA records, and so on. DNS is a
complicated beast, and any specification that exclusively contains
statements of the form "Let CAA(X) be the CAA record at DNS node X" is
oversimplified to the point where implementing it in practice will cause
problems.

-Tim

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+tim.hollebeek=digice...@lists.mozilla
.org] On Behalf Of Ben Laurie via dev-security-policy
Sent: Wednesday, November 29, 2017 3:37 PM
To: Paul Wouters <pa...@nohats.ca>
Cc: douglas...@gmail.com;
mozilla-dev-s...@lists.mozilla.org; Jeremy Rowley
<jeremy...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records

On 29 November 2017 at 22:33, Paul Wouters <pa...@nohats.ca> wrote:

>
>
> > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> > This whole conversation makes me wonder if CAA Transparency should
> > be a thing.
>
> That is a very hard problem, especially for non-DNSSEC signed ones.
>

Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear chain
of responsibility for keys, and that is relatively easy to build on.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Ryan Sleevi

unread,
Nov 30, 2017, 3:57:56 PM11/30/17
to Tim Hollebeek, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org, Paul Wouters, Ben Laurie, Jeremy Rowley
On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> The problem DNSSEC checks for CAA was intended to solve was the fact that
> it
> is certainly possible that a well-resourced attacker can manipulate the DNS
> responses that the CA sees as part of its CAA checks. A better mitigation,
> perhaps, is for multiple parties to publicly attest in a verifiable way as
> to what the state of DNS was at/near the time of issuance with respect to
> the relevant CAA records. This leads to the idea that perhaps it's worth
> exploring enhancing existing CT logging servers to do CAA checks and log
> what they see. That's probably easier than setting up an entirely separate
> infrastructure for CAA transparency. CT servers could even communicate
> back
> to CAs the results they see to assist in detecting and identifying both
> malicious and non-malicious discrepancies between the CA's own checks and
> what the CT log is seeing. "Thanks for the pre-cert. We see a CAA record
> at X.Y.Z.Z.Y that doesn't include you. Do you really want to issue?"
> There
> are legitimate concerns that giving even more work to CT log servers might
> put even more burden and expense onto those who are running CT log servers,
> but that can probably be figured out.
>

While I understand the intent of the suggestion, it basically boils down to:
- To solve independently verifying CAA, we need Trusted Third Parties
- We have CT logs (which are not meant to be TTPs)
- We should make logs TTPs so we don't have to spin up new TTP
infrastructure

The goal of CT from the get go has been that logs do not need to be TTPs,
and that this is achieved by the cryptographic properties of the design
combined with the ecosystem mitigations to detect any deviance. This is not
possible with a CAA-in-CT, because CT is fundamentally not designed to
provide cryptographic attestations about the statement of CAA (if we had
such attestations, the CA could provide them anyways).

So I don't think we can get away from the notion that if we want CAA to be
an independently-verified aspect, then you need either TTPs (and CT logs
are by design not TTPs, and should not be made TTPs) or you need to solve
the cryptographic verifiability (in which case, you don't need CT logs to
do this).

Of course, I think this is all conditioned on whether CAA's value is
somehow tied to the independently-verified. I don't believe that it is, no
more than we're requiring cryptographic proofs of CA's validation of OV/EV
documents or chains of custody from the QGIS and QIIS' used to validate
that data. Instead, CAA serves as a machine-readable expression of policy
intent, no different than having http://domain.com/.well-known/caa in some
machine readable form. Our primary benefit of having it expressed in DNS
(versus that HTTP-based file) is that we can leverage DNSSEC as a bootstrap
for trust when it's available (despite all of its warts - and cryptographic
issues) and it more easily aligns with CA's existing practices of DNS-based
validation.

It may be surprising to hear me suggesting that we expect something of CAs
without having it independently verified - but I think there's substantial
value to be afforded applicants/subscribers, and I'm deeply worried when
the suggestions we have to date are to introduce more TTPs, make explicitly
non-TTPs into TTPs, or to add unreliable reporting mechanisms that might
otherwise drive up the costs of a sensible risk mitigation technology.

I think for those that want to serve in a CAA Auditor role have the iodef
mechanism as a way of reporting potential strangeness in such a way that
the burden shifts to the applicant, but also that their ability to
recognize (or reject) such information is the most scalable solution.

Tim Hollebeek

unread,
Nov 30, 2017, 4:01:20 PM11/30/17
to ry...@sleevi.com, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org, Paul Wouters, Ben Laurie, Jeremy Rowley
I think there’s value in publicly logging things even if that isn’t the basis for trust. So I disagree that what I wrote boils down to what I didn’t write.



-Tim



From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, November 30, 2017 1:57 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ben Laurie <be...@google.com>; Paul Wouters <pa...@nohats.ca>; douglas...@gmail.com; mozilla-dev-s...@lists.mozilla.org; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records







Wayne Thayer

unread,
Nov 30, 2017, 4:07:21 PM11/30/17
to Tim Hollebeek, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley, douglas...@gmail.com, ry...@sleevi.com, Paul Wouters, Ben Laurie
What problem(s) are you trying to solve?

- Subscribers already (or soon will) have CT logs and monitors available to
detect mis-issued certs. They don't need CAA Transparency.

- This thread started as a discussion over possible mis-issuance that was
determined to be false positives. As has been stated, without DNSSEC there
is no such thing as a coherent view of DNS and Ryan described a legitimate
example where a domain owner may consciously update CAA records briefly to
permit issuance. It's unclear to me how CAA Transparency could solve this
problem and thus provide a mechanism to confirm mis-issuance, if that is
the goal.

- The goal of reducing the risk of mis-issuance from well-behaved CAs who
have bad or manipulated CAA data seems most worthwhile to me. To Ryan's
point (I think), there may be better ways of achieving this one such as
requiring CAs to "gossip" CAA records, or requiring CAA checks be performed
from multiple network locations.

Wayne

Tim Hollebeek

unread,
Nov 30, 2017, 4:17:35 PM11/30/17
to Wayne Thayer, mozilla-dev-s...@lists.mozilla.org, Jeremy Rowley, douglas...@gmail.com, ry...@sleevi.com, Paul Wouters, Ben Laurie
Wayne, your last point is closest to my thinking, and I whole-heartedly agree there may be better solutions. My suggestion was that if CAA transparency is a desired thing, and it is clear that at least a few people think it is worth considering, it’s probably better to do it with existing transparency mechanisms instead of making up new ones.



There’s a lot of CAA debugging going on in private right now, and there isn’t necessarily an a priori reason why it has to be private.



-Tim



From: Wayne Thayer [mailto:wth...@mozilla.com]
Sent: Thursday, November 30, 2017 2:07 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: ry...@sleevi.com; douglas...@gmail.com; mozilla-dev-s...@lists.mozilla.org; Paul Wouters <pa...@nohats.ca>; Ben Laurie <be...@google.com>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records



What problem(s) are you trying to solve?



- Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency.



- This thread started as a discussion over possible mis-issuance that was determined to be false positives. As has been stated, without DNSSEC there is no such thing as a coherent view of DNS and Ryan described a legitimate example where a domain owner may consciously update CAA records briefly to permit issuance. It's unclear to me how CAA Transparency could solve this problem and thus provide a mechanism to confirm mis-issuance, if that is the goal.



- The goal of reducing the risk of mis-issuance from well-behaved CAs who have bad or manipulated CAA data seems most worthwhile to me. To Ryan's point (I think), there may be better ways of achieving this one such as requiring CAs to "gossip" CAA records, or requiring CAA checks be performed from multiple network locations.



Wayne



Quirin Scheitle

unread,
Nov 30, 2017, 4:32:28 PM11/30/17
to ry...@sleevi.com, mozilla-dev-s...@lists.mozilla.org

> On 30. Nov 2017, at 15:52, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>> On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>> Similar to the GlobalSign discussion, it is well possible that the domain briefly disabled their CAA records when you did the check — and re-enabled them later.
>>
> I think that, as CAA deployment becomes common, this pattern will be not-uncommon. I would hope we don't sound false alarms when it does.
>

Hi Ryan,

thank you for your e-mail, I hear your concern.

We did apply tight filtering before raising any cases, and urge any other evaluators to do so as well.
We reported cases to CAs/this forum that seemed to hint at issues in CAA validation at CAs, such as the wildcard/nonwildcard mix.
We also don’t see our reports as “alarms”, but as cases that might warrant a closer look.

Domain records may change on short notice, and we carefully differentiated and analyzed each case.
Consistently setting “issue ;”, for example, lets one expect that a domain will change that for issuance.
Consistently reporting a set of CAs not including the issuing CA — not so much.
If you have the capability to change CAA records at each issuance, why maintain a set of non-issuing CAs in your CAA records?
Combined with configurations that can trigger corner cases (such as the wildcard/non-wildcard mix), we weighed these as worth reporting at that time.
Having learned that the latter cases happen as well, we will be even more sceptical for these going forward.

I honestly believe that we applied the maximum diligence that can be expected from an external evaluator, based on data that, depending on domain and time, was based on 8-hour or even 4-hour scan intervals *at issuance time*.

Kind regards
Quirin

Paul Wouters

unread,
Nov 30, 2017, 4:40:08 PM11/30/17
to Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
On Thu, 30 Nov 2017, Wayne Thayer wrote:

[cut CC: list, assuming we're all on the list]

> - Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency.

It's not for subscribers, but for CA's.

Transparency is nice, but it does not _prevent_ misissue. The goal of
CAA is to prevent misissue.

We don't need a CAA Transparency log, because the only thing that needs
logging is the DNSSEC chain of the CAA record or lack thereof at the
time of issue. And only the issuing CA needs this information in case
they need to defend that there was no CAA record preventing them from
issuing at the time. Of course, you could still stuff it in some
transparency log if you want, but it is pretty useless for endusers.

Paul

Paul Wouters

unread,
Nov 30, 2017, 4:54:09 PM11/30/17
to Tim Hollebeek, mozilla-dev-s...@lists.mozilla.org
On Thu, 30 Nov 2017, Tim Hollebeek via dev-security-policy wrote:

[somewhat off topic, you can safely hit delete now]

> So it turns out DNSSEC solves CAA problems for almost nobody, because almost
> nobody uses DNSSEC.

The only people who need to use CAA are the CA's. They can surely manage
to fire up a validating DNS resolver. I'm sure there are more BR's that
"almost nobody uses" because there is no need for everyone to use it but
CA's. If you talk about domain holders not being able to run DNSSEC,
that's a pretty lame excuse too, when we have many Registrars and
Hosters who run millions of DNSSEC secured zones. I feel this argument
is similar to "hosting your own email service is too hard". If it is,
there are excellent commercial alternatives available.

> And given the serious flaws both in DNSSEC itself and exiting DNSSEC implementations

For one, I'm not aware of "serious flaws in DNSSEC". As for wanting
something to die because of bad implementations, can I suggest starting
with ASN.1 and X.509, then move to crypto primitives and TLS ? :)

> The presence of DNSSEC in the BR policy
> for handling DNS failures, in hindsight, was probably a mistake, and

Trusting unauthenticated data from the network should really be a no-op,
from a princple point of view. Making any security decisions based on
"some blob from the network that anyone could have modified without
detecting" is just madness.

> Right now, the only thing it is really accomplishing is preventing certificate
> issuance to customers whose DNS infrastructure is flaky, misconfigured, or
> unreliable.

Seems like the kind of people who should be given a certificate award
for excellence :P

> Longer term, DNS over HTTPS is probably a more useful path
> forward than DNSSEC for CAA, but unfortunately that is still in it's
> infancy.

Not really, because that only offers transport security and not data
integrity. A compromised nameserver should not be able to fake the lack
of CAA record for a domain that uses secure offline DNSSEC signing.

> The problem DNSSEC checks for CAA was intended to solve was the fact that it
> is certainly possible that a well-resourced attacker can manipulate the DNS
> responses that the CA sees as part of its CAA checks. A better mitigation,
> perhaps, is for multiple parties to publicly attest in a verifiable way as
> to what the state of DNS was at/near the time of issuance with respect to
> the relevant CAA records.

Then why not simply cut out the DNS middle man, and give domains another
way to advertise this information. What about RDAP ? What about an EPP
"CA lock" similar to a "Registrar lock" ?

> Of course, to avoid some of the extremely interesting experiences the
> industry has had with CAA

Maybe people should use proper dns libraries and not invent their own
CNAME / DNAME handling :)

Paul

Quirin Scheitle

unread,
Nov 30, 2017, 5:10:41 PM11/30/17
to Wayne Thayer, mozilla-dev-s...@lists.mozilla.org
Hi all,

just 2 quick comments:

> On 30. Nov 2017, at 22:06, Wayne Thayer via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> This thread started as a discussion over possible mis-issuance that was
> determined to be false positives

We had reported 18 anomalies, of which my current (quick) count is 7 confirmed, 9 pending, and 2 false positives.
I do not think these numbers support a statement that the evaluator role is determined to create false positives.

> On 30. Nov 2017, at 21:12, Tim Hollebeek via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> So it turns out DNSSEC solves CAA problems for almost nobody, because almost
> nobody uses DNSSEC. And given the serious flaws both in DNSSEC itself and
> exiting DNSSEC implementations, it is unlikely to be part of any solution to
> the current problems CAA is facing

Of ~115k CAA-enabled base domains, we currently see 12% using DNSSEC.
Of these 12%, ~1% (a count of ~130) have invalid signatures.

I think those 12% would like to have the benefits of DNSSEC for CAA.

We are writing up a report about out investigations that has numbers on most of the questions discussed.
I will be happy to share it here it that would not be considered spam.

Kind regards
Quirin

Tim Hollebeek

unread,
Nov 30, 2017, 5:11:41 PM11/30/17
to mozilla-dev-s...@lists.mozilla.org

Paul,

Improving CAA by moving it to a protocol other than DNS is certainly worth
considering, going forward.

With respect to people using proper DNS libraries and not inventing their
own CNAME / DNAME handling, the problem was that RFC 6844 accidentally
specified semantics for CNAME / DNAME that were not the standard semantics!
Even the erratum discussed extensively last spring still isn't fully
compliant with the relevant RFCs.

About half of the CAA problems encountered could have been avoided if RFC
6844 had simply said "When doing CAA lookups, CNAME MUST be handled as
specified in RFC 2181, and DNAME MUST be handled as specified in RFC 6672",
without trying to explicitly include them in the lookup algorithm.

-Tim

Ryan Sleevi

unread,
Nov 30, 2017, 5:12:18 PM11/30/17
to Tim Hollebeek, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer, douglas...@gmail.com, Jeremy Rowley, ry...@sleevi.com, Paul Wouters, Ben Laurie
Right, and to my point:

Each transparency mechanism has to be specific to the problem it's trying
to solve. CT is not a magic cureall for transparency - it's specific to,
well, certificates, and more generally, TLS web certificates.

For things like S/MIME, you have "Key Transparency" (based on COINKS)
For things like binaries, you have "Binary Transparency"
For things like DNSSEC authority records, you could have "DNSSEC
transparency"

It would be a mistake to think CT is some cureall, just like it would be a
mistake to think "blockchain" suddenly solves all problems. The design of
the technology, and its assumptions about the ecosystem, are relevant.

The general problem of any *Transparency system is you need a way to
authenticate the data that is logged to some extent, and you need a way to
independently verify or evaluate that data. Certificates provide both
signatures and trust chains, so you get both. The constraints around
privacy of S/MIME certificates (which are unique to them) lend themselves
to a different technical solution, like Key Transparency.

As it relates to DNS, DNS sans-DNSSEC has no way to authenticate the data.
So either your authentication is to introduce TTPs that can log the data
(whether it's the Log or some multi-perspective contractually trusted
third-party) or you need to find a way to sign the data (which DNSSEC is).
Yet all that does is create a merkle hash tree - the system for ensuring
and validating consistency and accuracy of that is also going to depend on
the specific case.

I agree that the fact that a certificate must be disclosed to a log, and
that logs are independent of CAs, make it very easy and appealing to
suggest that logs should serve as the counterbalance to CAs. That's neither
the design nor the goal - logs are meant to be neutral record-keepers with
no trust afforded to them - with monitors/auditors/clients keeping them
honest, and anyone (not just CAs) being able to ask them to record the
facts.

There's obviously a gray area right now because of spec violations being
things you want to log, but you also don't want to normalize - and CT
Policy Days discussions around that continue to be interesting. But as it
relates to CAA Transparency, it's both confusing the purpose of CAA (a
machine readable expression of intent) and CT (no TTPs)

On Thu, Nov 30, 2017 at 4:16 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> Wayne, your last point is closest to my thinking, and I whole-heartedly
> agree there may be better solutions. My suggestion was that if CAA
> transparency is a desired thing, and it is clear that at least a few people
> think it is worth considering, it’s probably better to do it with existing
> transparency mechanisms instead of making up new ones.
>
>
>
> There’s a lot of CAA debugging going on in private right now, and there
> isn’t necessarily an a priori reason why it has to be private.
>
>
>
> -Tim
>
>
>
> *From:* Wayne Thayer [mailto:wth...@mozilla.com]
> *Sent:* Thursday, November 30, 2017 2:07 PM
> *To:* Tim Hollebeek <tim.ho...@digicert.com>
> *Cc:* ry...@sleevi.com; douglas...@gmail.com;
> mozilla-dev-s...@lists.mozilla.org; Paul Wouters <
> pa...@nohats.ca>; Ben Laurie <be...@google.com>; Jeremy Rowley <
> jeremy...@digicert.com>
> *Subject:* Re: Anomalous Certificate Issuances based on historic CAA
> records
>
>
>
> What problem(s) are you trying to solve?
>
>
>
> - Subscribers already (or soon will) have CT logs and monitors available
> to detect mis-issued certs. They don't need CAA Transparency.
>
>
>
> - This thread started as a discussion over possible mis-issuance that was
> determined to be false positives. As has been stated, without DNSSEC there
> is no such thing as a coherent view of DNS and Ryan described a legitimate
> example where a domain owner may consciously update CAA records briefly to
> permit issuance. It's unclear to me how CAA Transparency could solve this
> problem and thus provide a mechanism to confirm mis-issuance, if that is
> the goal.
>
>
>
> - The goal of reducing the risk of mis-issuance from well-behaved CAs who
> have bad or manipulated CAA data seems most worthwhile to me. To Ryan's
> point (I think), there may be better ways of achieving this one such as
> requiring CAs to "gossip" CAA records, or requiring CAA checks be performed
> from multiple network locations.
>
>
>
> Wayne
>
>
>

Jeremy Rowley

unread,
Nov 30, 2017, 5:24:24 PM11/30/17
to ry...@sleevi.com, Tim Hollebeek, Ben Laurie, Paul Wouters, douglas...@gmail.com, mozilla-dev-s...@lists.mozilla.org, Wayne Thayer
I think we can be more transparent about CAA records without requiring CT. I don’t have a solution, but more transparency about processing CAA records couldn’t hurt.



From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, November 30, 2017 3:12 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Wayne Thayer <wth...@mozilla.com>; ry...@sleevi.com; douglas...@gmail.com; mozilla-dev-s...@lists.mozilla.org; Paul Wouters <pa...@nohats.ca>; Ben Laurie <be...@google.com>; Jeremy Rowley <jeremy...@digicert.com>
Subject: Re: Anomalous Certificate Issuances based on historic CAA records



Right, and to my point:


Each transparency mechanism has to be specific to the problem it's trying to solve. CT is not a magic cureall for transparency - it's specific to, well, certificates, and more generally, TLS web certificates.



For things like S/MIME, you have "Key Transparency" (based on COINKS)

For things like binaries, you have "Binary Transparency"

For things like DNSSEC authority records, you could have "DNSSEC transparency"



It would be a mistake to think CT is some cureall, just like it would be a mistake to think "blockchain" suddenly solves all problems. The design of the technology, and its assumptions about the ecosystem, are relevant.



The general problem of any *Transparency system is you need a way to authenticate the data that is logged to some extent, and you need a way to independently verify or evaluate that data. Certificates provide both signatures and trust chains, so you get both. The constraints around privacy of S/MIME certificates (which are unique to them) lend themselves to a different technical solution, like Key Transparency.



As it relates to DNS, DNS sans-DNSSEC has no way to authenticate the data. So either your authentication is to introduce TTPs that can log the data (whether it's the Log or some multi-perspective contractually trusted third-party) or you need to find a way to sign the data (which DNSSEC is). Yet all that does is create a merkle hash tree - the system for ensuring and validating consistency and accuracy of that is also going to depend on the specific case.



I agree that the fact that a certificate must be disclosed to a log, and that logs are independent of CAs, make it very easy and appealing to suggest that logs should serve as the counterbalance to CAs. That's neither the design nor the goal - logs are meant to be neutral record-keepers with no trust afforded to them - with monitors/auditors/clients keeping them honest, and anyone (not just CAs) being able to ask them to record the facts.



There's obviously a gray area right now because of spec violations being things you want to log, but you also don't want to normalize - and CT Policy Days discussions around that continue to be interesting. But as it relates to CAA Transparency, it's both confusing the purpose of CAA (a machine readable expression of intent) and CT (no TTPs)



On Thu, Nov 30, 2017 at 4:16 PM, Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> > wrote:

Wayne, your last point is closest to my thinking, and I whole-heartedly agree there may be better solutions. My suggestion was that if CAA transparency is a desired thing, and it is clear that at least a few people think it is worth considering, it’s probably better to do it with existing transparency mechanisms instead of making up new ones.



There’s a lot of CAA debugging going on in private right now, and there isn’t necessarily an a priori reason why it has to be private.



-Tim



From: Wayne Thayer [mailto:wth...@mozilla.com <mailto:wth...@mozilla.com> ]
Sent: Thursday, November 30, 2017 2:07 PM
To: Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> >
Cc: ry...@sleevi.com <mailto:ry...@sleevi.com> ; douglas...@gmail.com <mailto:douglas...@gmail.com> ; mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> ; Paul Wouters <pa...@nohats.ca <mailto:pa...@nohats.ca> >; Ben Laurie <be...@google.com <mailto:be...@google.com> >; Jeremy Rowley <jeremy...@digicert.com <mailto:jeremy...@digicert.com> >
Subject: Re: Anomalous Certificate Issuances based on historic CAA records



What problem(s) are you trying to solve?



- Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency.



- This thread started as a discussion over possible mis-issuance that was determined to be false positives. As has been stated, without DNSSEC there is no such thing as a coherent view of DNS and Ryan described a legitimate example where a domain owner may consciously update CAA records briefly to permit issuance. It's unclear to me how CAA Transparency could solve this problem and thus provide a mechanism to confirm mis-issuance, if that is the goal.



- The goal of reducing the risk of mis-issuance from well-behaved CAs who have bad or manipulated CAA data seems most worthwhile to me. To Ryan's point (I think), there may be better ways of achieving this one such as requiring CAs to "gossip" CAA records, or requiring CAA checks be performed from multiple network locations.



Wayne



Gervase Markham

unread,
Dec 1, 2017, 5:42:52 AM12/1/17
to ry...@sleevi.com, Quirin Scheitle, Jeremy Rowley
On 30/11/17 14:52, Ryan Sleevi wrote:
> I think that, as CAA deployment becomes common, this pattern will be
> not-uncommon. I would hope we don't sound false alarms when it does.

After a little time (as it does seem some bugs are still being shaken
out), I am considering having Mozilla adopt a policy either of:

a) not accepting CAA violation reports from people other than the owners
of the domain in question; or

b) automatically believing the CA if they post a log which shows their
view of the DNS at the time of issuance.

We could start with b), but if CAs get a high load of reports still, we
could move to a).

Gerv
0 new messages