An Empirical Survey on the Early Adoption of DNS Certification

Authority Authorization

Jukka Ruohonena

aDepartment of Future Technologies, University of Turku, Finland (juanruo@utu.fi)

ARTICLE HISTORY

Compiled April 23, 2018

ABSTRACTA new certification authority authorization (CAA) resource record for the domainname system (DNS) was standardized in 2013. Motivated by the later 2017 deci-sion to enforce mandatory CAA checking for most certificate authorities, this papersurveys the early adoption of CAA by using an empirical sample collected fromthe Alexa’s top-million domains. According to the results, (i) the adoption of CAAis still at a modest level; only a little below two percent of the popular domainssampled have adopted CAA. Among the domains that have adopted CAA, (ii) au-thorizations dealing with wildcard certificates are rare compared to conventionalcertificates. Interestingly, (iii) the results only partially reflect the market structureof the global certificate business. With these timely results, the paper contributesto the ongoing large-scale empirical research on the use of encryption technologies.

KEYWORDSdomain name system, certificate authority, public key infrastructure, HTTPS, TLS

1. Introduction

The CAA resource record (RR) passed formal standardization in 2013.1 It was onlyfour years later, in March 2017, when many certificate authorities (CAs) were man-dated to implement CAA checking [14]. This decision was celebrated due to increasingconcerns about the issuance of fraudulent or rogue certificates in the global public keyinfrastructure (PKI). Although CAA is only a small step toward better PKI security,these concerns are a good way to briefly motivate the paper’s empirical survey on theadoption and use of the new CAA resource record among popular Internet domains.

The transport layer security (TLS) and its predecessor, the secure sockets layer(SSL), constitute the almost universally adopted cryptographic protocols for estab-lishing communications security in the Internet and the world wide web in particular.These protocols have largely also survived the test of time. While many revisions andalterations have been required to patch the protocols, no cryptographic vulnerabilityis known to exist that would allow to fully compromise the underlying end-to-end se-curity model. This said, a number of high-profile TLS/SSL vulnerabilities (includingthe so-called Heartbleed, FREAK, and DROWN) have been discovered and disclosed

1 This manuscript was submitted for double-blind peer review to Journal of Cyber Security Technology (ISSN:2374-2917) in November 6, 2017. After this submission, two relevant papers have been published: [5] and [32].

A reader should consult these papers in addition to this manuscript.

arX

iv:1

804.

0760

4v1

[cs

.CR

] 2

0 A

pr 2

018

in recent years [25,34]. In addition to these vulnerabilities, a long-standing weaknessoriginates from the global PKI and its CA-based trust model [12,16]. This type ofa weakness is also what motivated the standardization and the later enforcement ofCAA checking among most certificate authorities.

The TLS protocol uses public-key cryptography for the initial exchange of keys. Ifthe exchange is successful, symmetric encryption is used afterwards. The PKI-inducedweakness exposes itself through server authentication. When a client connects to aweb server using TLS, the client’s web browser verifies the server’s certificate (key)by evaluating it against a set of trusted certificates signed by trusted but still third-party authorities. This evaluation places the trust provision entirely into the hands ofcertificate authorities. In principle, a CA can sign a certificate for any domain, andthis certificate will be trusted by most web browsers and operating systems. There arehundreds of CAs located in almost every corner of the world, and all of these CAs areequally trusted [8]. What is more, the trust relationship is transitive: web browsersand operating systems will trust certificates issued also by intermediate authorities [2].These fundamental pillars of the global PKI allow to understand why it can be desir-able to only trust some CAs and mistrust others. To put theoretical issues aside, therehave been two tangential real-world weaknesses in this trust model.

On one hand, the history knows many cases of erroneous signing of certificates byCAs [23]. For instance, in 2001 two certificates were issued by VeriSign in Microsoft’sname to an individual not affiliated with Microsoft [12]. While VeriSign sold its certifi-cate business to Symantec later in 2010, controversies continued. For instance, recentlyin March 2017, Google blamed Symantec for incorrectly issuing tens of thousands ofcertificates [6]. A few months later, in August 2017, Symantec in turn sold its certifi-cate business to DigiCert, but regardless of the ownership, the controversies are likelyto continue about the rigor (or lack thereof) that CAs use for certificate issuance.

On the other hand, the trust provision has exposed a more pressing concern aboutthe security of the CAs themselves. Any CA is a lucrative target for attacks. In additionto limiting the availability of a CA through denial-of-service attacks [22], compromisinga CA opens numerous possibilities for tampering with confidentiality and integrity,including issuance of rogue certificates, stealing or substituting keys used for signing,and manipulating requests for issuing valid certificates for fraudulent purposes [13,17].These scenarios are not only theoretical. The likely most well-known attack occurred in2011 against the Dutch certificate authority DigiNotar, which later went also bankruptdue to the attack. By compromising the CA, an attacker was able to issue a wildcardcertificate for Google’s main domain, which was subsequently used to conduct man-in-the-middle attacks against users in Iran [20]. The same pattern had already occurreda few months earlier when another certificate authority, Comodo, was compromised.Both cases led to speculations about the potential involvement of state-level actors.Such speculations have also intensified in recent years due to numerous legislativechanges made to increase the power of national intelligence agencies [8]. For instance,concerns were raised in October 2017 about the implications of a Dutch law for trustingthe national, state-level CA of the Netherlands [7]. On the bright side, the attacks andthe controversies led to many initiatives for improving the security of the global PKI.

The current initiatives for improving TLS/PKI security are too voluminous [38] toadequately summarize in the present context. Nevertheless—insofar as the certificateissuance problems are considered, the standardization of the so-called certificate trans-parency [19] is noteworthy because it enables auditing of CAs through publicly avail-able logs. Although there is still room for improvements, the transparency logs havealso proven useful for better understanding the Internet-wide TLS/PKI ecosystem [36].

2

Given the increasing concerns about the ever increasing mass surveillance [11,33], alsothe so-called Let’s Encrypt (LE) initiative is worth remarking. By offering a free cer-tificate and easy configuration options, the initiative is noteworthy as it attempts todemocratize certificate issuance by challenging both the state-led mass surveillanceendeavors and the global certificate business [1]. The initiative also supports and re-spects certification authorization [21], which is one of the standardized initiatives forimproving TLS/PKI security. Before proceeding to discuss CAA in detail, it shouldbe emphasized that the rationale behind CAA is to address the first weakness type,the erroneous issuance of certificates. This rationale is implemented through DNS byallowing any domain name owner to restrict the issuance of certificates by CAs.

2. Certification Authority Authorization

The CAA resource record type was created to allow a domain name owner to specifythose certificate authorities who are allowed to issue certificates for the domain name.Before issuing certificates for domains, CAs evaluate the presence of CAA records vialive DNS resolving. If the records are either missing or the records specifically autho-rize a given CA, the certificate authority is permitted to proceed with the certificateissuance. In essence, therefore, CAA provides an additional assertion to prevent erro-neous or accidental issuance of certificates. This DNS-based authorization mechanismneither addresses nor prevents threats originating from the insecurity of certificateauthorities. That is: by compromising a CA, it is presumably trivial to also bypassCAA checking when issuing rogue certificates or conducting some related attacks.

The RFC 6844 specification [15] for CAA is fairly simple. The RR structure containsflags, tags, and values. Currently, only the so-called critical flag is defined. Specifyingthis flag instructs a CA to not issue a certificate in case the CA does not implement orunderstand the semantics of a given tag-value pair. There are three valid tags: (1) theissue tag is used to define a certificate authority who is authorized to issue certificatesfor the domain in question; (2) the issuewild tag is similar but authorizes the issuanceof wildcard certificates; and (3) the iodef tag enables the use of a standardized messageexchange format [9] to report CAA-related problems to the owner of the domain. Forthe issue and issuewild tags, the value specifies the CA who is authorized. An emptyvalue is interpreted to disallow the issuance. For instance, the following imaginaryrecord disallows the issuance of wildcard certificates, while permitting DigiCert to issuenormal certificates and instructing CAs to use electronic mail for reporting problems:

example.com CAA 0 issuewild ";"

example.com CAA 0 issue "digicert.com"

example.com CAA 0 iodef "mailto:root@example.com"

Despite of this simple format, many DNS servers and tools do not yet support theCAA resource record. In addition to this lack of supporting software, the current adop-tion challenges relate to domain name aliases, the lack of clearly defined accountingcriteria on how CAs are evaluating CAA records in practice, and configuration prob-lems for multinational companies who may control hundreds of domains and theirsubdomains [27]. While many of these problems likely continue to hinder adoption,the question about domain name aliases is directly relevant also for this paper. Inother words, a few details about the empirical sample should be elaborated beforeproceeding to evaluate the adoption of the certification authority authorization.

3

3. Data

The empirical sample is based on the Alexa’s top-million busiest domains [4]. Althoughsome skepticism is warranted about the representativeness of the list particularly inthe DNS context [37], the list is commonly used as a benchmark in large-scale empiricalstudies exploring TLS/PKI [35,36], among other Internet measurement topics [10,30].Because the paper’s focus is restricted to DNS, a simple client-side DNS resolver [29]was used to query for CAA resource records of each domain in the Alexa’s popularitylist using Google’s name server at 8.8.8.8. This querying requires a brief elaboration.

Each domain in the list was resolved three times in order to rule out timeouts andother temporary resolution failures. The same applies to further resolving required toprocess the CAA records from the viewpoint of certificate authorities [15]. For dealingwith aliases (CNAMEs), a generally recommended upper limit [18] is used by fixing themaximum number of recursive queries to eight. This recursion depth is also noted inthe errata for the CAA standard [26]. As an example: if the CAA records of a domaina.b.c are aliased to d.e.f, which in turn has a CNAME pointing to g.h.i, after tworecursive queries (for resolving d.e.f and g.h.i), the CAA records of g.h.i are usedfor a.b.c, provided that these are present. If this recursive search does not find CAArecords, the records are queried by moving upward in the DNS hierarchy until the top-level domain (TLD) name is reached [15]. For instance: if no CAA records are found bytraversing the CNAME chain of a.b.c, the CAA records of b.c, if present, are usedfor the domain a.b.c. If also this hierarchical query fails, the domain a.b.c is finallyconcluded to operate without CAA records, given that the subsequent hierarchicallevel denotes a top-level domain to which the hierarchical querying does not traverse.

A brief semantic validation is carried out for each CAA record. Namely: (1) eachresource is verified to include a flag, a tag, and a value; (2) flags are asserted to equal128, one, or zero; (3) tags are validated to be either issue, issuewild, or iodef ; and (4)values specified with iodef are checked to start either with the character string mailto

or with the string http. These basic checks caught a few small errors in the specifi-cations of the CAA records among the domains sampled. For instance, a few domainsomit the mailto, http, or https prefixes when specifying values for the iodef tag. Alsoother innocent mistakes are present: the domains manned.org, thousandwonders.net,vncg.org, and yorhel.nl have tried to specify wildcard authorizations but spelledthe corresponding tag as issuewold. Likewise, the domain globo.com has spelled theiodef tag as ideof, and the domain hivolda.no has specified two flags. While thesefew cases are statistical outliers, the cases are excluded to ensure consistent parsing.It is worth to also remark that it would be possible to carry out further validation byresolving also the authorized domains, including the mail exchange (MX) records forthe email addresses delivered via the iodef tag. As the focus of the paper is on theadoption of CAA, such validation experiments can be left for further work, however.

4. Results

The dataset obtained via live DNS resolving contains 16086 domains with CAA re-source records. Thus, in absolute terms, the adoption is still at a rather modest level:only about 1.6% of the domains in the Alexa’s top-million list have specified certifi-cation authority authorizations in their DNS records. Even though existing scholarlyresearch is limited, there are good reasons to suspect that the pace of adoption hasincreased after the CAA checking was voted as mandatory for certificate authorities

4

participating in the CA/Browser Forum. For instance, only 307 domains out of Alexa’stop-million list were reported to have deployed CAA records in early April 2017 [3].If this amount is used as a coarse heuristic, the adoption has increased by over 5000%in about six months. To a small extent, the adoption has been slower among morepopular domains compared to less popular domains. This observation is illustrated inFig. 1, which shows the presence of CAA records across Alexa’s popularity rank. Al-though com is the most frequent TLD among the sampled domains with CAA records,also many country-code TLDs appear in the ranking shown in Fig. 2.

0 200000 400000 600000 800000 1000000

Alexa rank

CAA records

No

Yes

N = 983914

N = 16086

Figure 1. Presence of CAA Records and Alexa’s Popularity Ranks

com id br jp in es de mx gr it tw ru eg0

10203040506070

Shar

e (%

)

TLD

56.4%

6.5% 5.4% 3.1% 2.9% 2.3% 2.1% 2.1% 2.0% 1.5% 1.4% 1.1% 1.0%

Relative share of top-13 TLDs across domains with CAA records

Figure 2. Domains with CAA Records According to TLDs

issue

Domains authorized

0 2 4 6 8 10

Frequ

ency

0

5000

10000

15000 Min = 0 Max = 10 Mean = 1.1 Median = 1 Std. dev. = 0.6

issuewild

Domains authorized

0 2 4 6 8 10

Frequ

ency

0

5000

10000

15000 Min = 0 Max = 7 Mean = 0 Median = 0 Std. dev. = 0.2

Figure 3. Domains Authorized

On average, most of the domains with CAA records authorize only one CA. Mostof these authorizations authorize CAs to issue only normal certificates. Authorizationsinvolving wildcard certificates are less common (see Fig. 3). The so-called DNS graphsoffer a good method to elaborate these observations further.

By using a common undirected and bipartite DNS graph representation [31], thereare two types of vertices: the domains sampled from the Alexa’s list and the domains

5

the sampled domains have authorized via the issue or the issuewild tags. Whenever agiven “Alexa-domain” has authorized a “CA-domain”, an edge is placed between thesetwo types of domain vertices. A resulting graph representation is illustrated in Fig. 4by connecting the domains sampled (as represented by the green vertices with theirsizes proportional to Alexa’s popularity ranks) to the CA-domains (as representedby blue vertices) that the sampled Alexa-domains have authorized to issue wildcardcertificates. By constructing an analogous bipartite graph according to the issue tag,the most frequently authorized domains can be summarized by calculating the numberof adjacent vertices to the Alexa-domains. The results from this calculation are shownin Fig. 5. There are many relevant observations to make from these two figures.

All of the big commercial CAs are represented, but the CAA authorizations do notentirely reflect the market shares of the CA companies [24]. Interestingly, neither arethe numerous acquisitions and other changes in the market structure (yet) reflectedin the results. What is more important, the most frequently authorized domain in theissue graph is Google’s pki.goog. This observation does not mean that many domainswould authorize Google to issue certificates. The explanation rather is that many ofGoogle’s domains are popular, and, hence, present also in the Alexa’s top-million list.A closer look reveals that out of the 8954 domains connected to pki.goog in theissue graph, as much as 8574 contain the character string blogspot. These cases alsoreflect the resolving strategy; the CAA records for most of these cases were resolvedvia DNS hierarchy. In fact, out of the 16086 domains with CAA records, only threewere obtained via the CNAME traversing, about 14% were directly available, and asmuch as 86% were retrieved by moving upward in the DNS hierarchy. A majority ofthe hierarchical resolving cases refer to Google’s domains.

The large disconnected subgraph in Fig. 4 represents domains that have disallowedthe issuance of wildcard certificates for all authorities by specifying empty valuesfor their issuewild tags. Given the concerns about erroneous certificate issuance, thisobservation can be seen as a positive finding. However, all of these 170 domains haveaccompanied their empty issuewild tags with non-empty issue tags, meaning that thedomains have still authorized CAs to issue normal certificates. It is also noteworthythat the amount of self-loops is only eight and fifteen in the issue and issuewild graphs,respectively. In other words, only a few domains have authorized themselves. Whiledigicert.com is among these domains, most of these cases likely refer to deploymentsoperating with self-signed certificates.

It is interesting to observe that many of the authorized CAs tend to cluster into theirown dense subgraphs that are only sparsely connected to other clustered subgraphs.While this observation is a typical finding in empirical graph mining applications [28],the contextual interpretation is more interesting than statistical clustering as such. Toaid the interpretation, Fig. 7 displays six subgraphs that include those vertices andedges that are two steps away from the labeled domains authorized via the issue tag.

The presence of dense subgraphs means that most Alexa-domains tend to only au-thorize one CA-domain, which is understandable because most certificates cost money.Interestingly, however, the domains that have authorized letsencrypt.org via the is-sue tag tend to form a more dense subgraph than many of the domains that have au-thorized commercial CAs. Even though LE is less frequently authorized than DigiCert(see Fig. 5), for instance, this result likely again reflects the sampling from the Alexa’slist. In other words, the most popular domains are not the primary target audience ofthe LE initiative. The denseness of the LE-subgraph in Fig. 7 likely reflects this targetaudience. In absolute terms, the results also implicitly correlate rather well with pre-vious results according to which about 5% of domains in the Alexa’s top-million list

6

quovadisglobal.com

geotrust.com

comodoca.com

digicert.com

symantec.com

thawte.com

godaddy.com

Empty (disallowed)

globalsign.com

letsencrypt.org

rapidssl.com

comodo.com

yandex.ru

amazon.com

amazonaws.com

Authorized domain (issuewild)Domain (size scaled by Alexa rank)

Figure 4. Bipartite DNS-CAA Graph According to Wildcard Authorization

amazonaws.comamazontrust.com

yandex.ruquovadisglobal.com

pki.dfn.deentrust.netcertsign.ro

startcomca.comEmpty (disallowed)

comodo.comthawte.com

rapidssl.comgeotrust.comamazon.comgodaddy.com

symantec.comglobalsign.comcomodoca.comletsencrypt.org

digicert.compki.goog

issue

Top-20 authorizeddomains (y-axis)

Authorizations (degree)

0 4000 8000

wisekey.comcertum.pl

awstrust.comstarfieldtech.comamazontrust.com

entrust.netamazonaws.com

comodo.comrapidssl.comthawte.com

quovadisglobal.comyandex.ru

amazon.comletsencrypt.orgsymantec.com

geotrust.comgodaddy.com

globalsign.comdigicert.com

comodoca.comEmpty (disallowed)

issuewild

Top-20 authorizeddomains (y-axis)

Authorizations (degree)

0 50 100 150 200

Figure 5. Most Frequently Authorized Domains

0 1 128

issue

0

5000

10000

15000

Flags (value set)

Autho

rization

s

0 1 128

issuewild

0200400600800

Flags (value set)

Autho

rization

s

Figure 6. Flags Set for the Authorizations

7

Empty (disallowed)

Authorized domain (issue)Domain

godaddy.com

symantec.com

comodoca.com

letsencrypt.org

pki.goog

Figure 7. Six DNS-CAA Subgraphs (two hops from the labels shown, issue)

steppingstone@nedap.comit@anydesk.com

adm@tensquaregames.comnoc@emgag.com

caa@mbank.plcaa-report@chsc.dk

systems@reinvent.comcert-request-l@monash.edu

it-systemhaus.vertrauensdienste@arbeitsagentur.dewebmaster@mobilcom.dedns-admin@wikimedia.org

klermontfonthated@gmail.comsecurity@craigslist.org

security@yahoo.comdl-ebay-caa@ebay.com

content-delivery+caa@tumblr.com

0 1000 2000 3000 4000 5000

Frequency

Most frequent reporting targets:

iodef

0 25 50 75 100

http

https

mailto

Share (%)

Type

0.00%

0.07%

99.93%

Figure 8. A Summary of Reporting Targets

8

used a LE’s certificate in late 2016 [1]. While also the earlier remark about Google’sdomains is vividly reinforced by the subgraph illustration in Fig. 7, the upper-leftsubgraph is also noteworthy because it indicates the presence of a few configurationmistakes. That is, specifying both an empty value and a specified issuer is identical tospecifying just the specified issuer alone [15]. Analogous point can be made regardingthe flags specified for authorizations; a few domains have set a value one rather thanthe value 128 for specifying the critical flag (see Fig. 6). Finally, most of the domainsthat have used the iodef tag prefer electronic mail for reporting CAA-related issues(see Fig. 8). The majority of the domains with CAA records (about 65%, to be precise)have not bothered to announce any contact details, however.

5. Conclusion

This paper surveyed the adoption of the certification authority authorization. By usinga dataset based on live DNS resolving of domains in the Alexa’s top-million list, theadoption of CAA was observed to still be at a modest level. Among the domains thathave specified CAA records in their DNS configurations, the authorization of normalcertificates is more common than the authorization of wildcard certificates. In fact,many domains explicit disallow CAs to issue wildcard certificates. In terms of theauthorized CAs, the results reported reflect only partially the market structure ofthe global certificate business. In addition to new initiatives such as Let’s Encrypt,particularly the domains owned by Google have pushed the adoption of CAA forward.These results align well with the continuing concerns about weaknesses in the globalTLS/PKI ecosystem. Four limitations can be also noted for further work on CAA.

The paper’s scope was strictly restricted to DNS. Therefore, (1) further research isrequired for better understanding how the DNS-based certificate authorizations cor-relate with the actual issuance of certificates by certificate authorities. The certificatetransparency logs provide a good empirical source to examine such correlations. Thetopic is important because CAA does not impose any technique for validating whethera CA is properly evaluating CAA resource records [27]. Likewise, the use of DNS se-curity (DNSSEC) is strongly recommended to be used in conjunction with CAA [15].Although this conjunction was not examined in this paper, (2) it should be addressedin further empirical research. Nor did the paper attempt to track the adoption acrosstime. Given that CAA checking was recently voted to be mandatory for most cer-tificate authorities, (3) further research is also needed to systematically track CAA’sfuture longitudinal evolution in different areas. For instance, an interesting topicalarea relates to the future adoption of CAA among content delivery networks and theirDNS infrastructures. Finally, the sample used in the paper was restricted to the mostpopular domains. As this restriction presumably entails some biases for observingnew TLS/PKI openings such as LE, (4) further work is required to evaluate differentsampling strategies for large-scale empirical Internet measurement experiments.

References

[1] Aertsen, M., Korczynski, M., Moura, G. C. M., Tajalizadehkhoob, S., and van den Berg, J.(2017). No Domain Left Behind: Is Let’s Encrypt Democratizing Encryption? In Proceedingsof the Applied Networking Research Workshop (ANRW 2017), pages 48–54, Prague. ACM.

[2] Akhawe, D., Amann, B., Vallentin, M., and Sommer, R. (2013). Here’s My Cert, So

9

Trust Me, Maybe?: Understanding TLS Errors on the Web. In Proceedings of the 22ndInternational Conference on World Wide Web (WWW 2013), pages 59–70, Rio de Janeiro.ACM.

[3] Aleksandersen, D. (2017). Stop CAs from Misissuing Certificates for Your Domains withCAA Records. Ctrl Blog, 4 April. Available online in October 2017: https://www.ctrl.blog/entry/dns-caa.

[4] Alexa Internet, Inc. (2017). The Top Million Websites. Data feed retrieved in 21October (monthly averages, daily updates): http://s3.amazonaws.com/alexa-static/

top-1m.csv.zip.[5] Amann, J., Gasser, O., Scheitle, Q., Brent, L., Carle, G., and Holz, R. (2017). Mission

Accomplished?: HTTPS Security After DigiNotar. In Proceedings of the 2017 InternetMeasurement Conference (IMC 2017), pages 325–340, London. ACM.

[6] BBC (2017). Google and Symantec Clash on Website Security Checks. Available onlinein October 2017: http://www.bbc.com/news/technology-39365315.

[7] Chirgwin, R. (2017). Mozilla Devs Discuss Ditching Dutch CA, Because Cryptowars: WeDon’ Want no STEENKIN’ Proxies, As Will Be Possible Under New Local Laws. TheRegister, 30 October. Available online in October 2017: https://www.theregister.co.uk/2017/10/30/mozilla_mistrust_dutch_ca/.

[8] Dacosta, I., Ahamad, M., and Traynor, P. (2012). Trust No One Else: Detecting MITMAttacks Against SSL/TLS Without Third-Parties. In Foresti, S., Yung, M., and Martinelli,F., editors, Proceedings of the European Symposium on Research in Computer Security (ES-ORICS 2012), Lecture Notes in Computer Science (Volume 7459), pages 199–216, Pisa.Springer.

[9] Danyliw, R., Meijer, J., and Demchenko, Y. (2007). The Incident Object DescriptionExchange Format (RFC 5070). Internet Engineering Task Force (IETF). Available onlinein October 2017: https://www.ietf.org/rfc/rfc5070.txt.

[10] Delamore, B. and Ko, R. K. L. (2015). A Global, Empirical Analysis of the ShellshockVulnerability in Web Applications. In Proceedings of the IEEE Trustcom/BigDataSE/ISPA2015, pages 1129–1135, Helsinki. IEEE.

[11] Farrell, S. and Tschofenig, H. (2014). Pervasive Monitoring Is an Attack (RFC 7258).Internet Engineering Task Force (IETF). Available online in October 2017: https://tools.ietf.org/html/rfc7258.

[12] Forno, R. and Feinbloom, W. (2001). Inside Risks: PKI: A Question of Trust and Value.Communications of the ACM, 44(6):120–120.

[13] Grimm, J. (2016). PKI: Crumbling Under the Pressure. Network Security, (5):5–7.[14] Hall, K. (2017). Results on Ballot 187 – Make CAA Checking Mandatory.

The CA/Browser Forum. Available online in October 2017: https://cabforum.org/

pipermail/public/2017-March/009988.html.[15] Hallam-Baker, P. and Stradling, R. (2013). DNS Certification Authority Authorization

(CAA) Resource Record (RFC 6844). Internet Engineering Task Force (IETF). Availableonline in October 2017: https://tools.ietf.org/html/rfc6844.

[16] Hunt, R. (2001). Technological Infrastructure for PKI and Digital Certification. ComputerCommunications, 24(14):1460–1471.

[17] Kim, D., Kwon, B. J., and Dumitras, T. (2017). Certified Malware: Measuring Breachesof Trust in the Windows Code-Signing PKI. In Proceedings of the ACM Conference onComputer and Communications Security (CCS 2017), pages 1435–1448, Dallas. ACM.

[18] Kumar, A., Postel, J., Neuman, C., Danzig, P., and Miller, S. (1993). Common DNSImplementation Errors and Suggested Fixes (RFC 1536). Internet Engineering Task Force(IETF). Available online in March 2017: https://www.ietf.org/rfc/rfc1536.txt.

[19] Laurie, B., Langley, A., and Kasper, E. (2013). Certificate Transparency (RFC 6962).Internet Engineering Task Force (IETF). Available online in October 2017: https://tools.ietf.org/html/rfc6962.

[20] Leavitt, N. (2011). Internet Security under Attack: The Undermining of Digital Certifi-cates. Computer, 44(12):17–20.

10

[21] Let’s Encrypt (2017). Certificate Authority Authorization (CAA). Available online inNovember 2017: https://letsencrypt.org/docs/caa/.

[22] Lin, J., Jing, J., and Liu, P. (2012). Evaluating Intrusion-Tolerant Certification AuthoritySystems. Quality and Reliability Engineering International, 28(8):825–841.

[23] Meyer, C. and Schwenk, J. (2014). SoK: Lessons Learned from SSL/TLS Attacks. InKim, Y., Kim, H., and Perrig, A., editors, Proceedings of the International Workshop on In-formation Security Applications (WISA 2013), Lecture Notes in Computer Science (Volume8267), pages 189–209, Jeju Island. Springer.

[24] Netcraft, Ltd. (2015). SSL Survey. Available online in November 2017: https://www.netcraft.com/internet-data-mining/ssl-survey/.

[25] Oh, S., Kim, E., and Kim, H. (2016). Empirical Analysis of SSL/TLS Weaknesses in RealWebsites: Who Cares? In Choi, D. and Guilley, S., editors, Proceedings of the InternationalWorkshop on Information Security Applications (WISA 2016), Lecture Notes in ComputerScience (Volume 10144), pages 174–185, Jeju Island. Springer.

[26] RFC Editor (2017). RFC Errata for RFC 6844. Available online in October 2017: https://www.rfc-editor.org/errata/rfc6844.

[27] Rowley, J. (2017). The Latest on Certification Authority Authorization. CA Secu-rity Council. Available online in November 2017: https://casecurity.org/2017/03/21/the-latest-on-certification-authority-authorization/.

[28] Ruohonen, J., Holvitie, J., Hyrynsalmi, S., and Leppanen, V. (2016). Exploring theClustering of Software Vulnerability Disclosure Notifications Across Software Vendors. InProceedings of the 13th ACS/IEEE International Conference on Computer Systems andApplications (AICCSA 2016), pages 1–8, Agadir. IEEE.

[29] Ruohonen, J. and Leppanen, V. (2016). On the Design of a Simple Network Resolver forDNS Mining. In Proceedings of the 17th International Conference on Computer Systemsand Technologies (CompSysTech 2016), pages 105–112, Palermo. ACM.

[30] Ruohonen, J. and Leppanen, V. (2017a). How PHP Releases Are Adopted in the Wild?In Proceedings of the 24th Asia-Pacific Software Engineering Conference (APSEC 2017),pages 71–80, Nanjing. IEEE.

[31] Ruohonen, J. and Leppanen, V. (2017b). Investigating the Agility Bias in DNS GraphMining. In Proceedings of the 17th IEEE International Conference on Computer and Infor-mation Technology (IEEE CIT 2017), pages 253–260, Helsinki. IEEE.

[32] Scheitle, Q., Chung, T., Hiller, J., Gasser, O., Naab, J., van Rijswijk-Deij, R., Hohlfeld,O., Holz, R., Choffnes, D., Mislove, A., and Carle, G. (2018). A First Look at Certifica-tion Authority Authorization (CAA). ACM SIGCOMM Computer Communication Review,48(2):1–13.

[33] Schuster, S., van den Berg, M., Larrucea, X., Slewe, T., and Ide-Kostic, P. (2017). MassSurveillance and Technological Policy Options: Improving Security of Private Communica-tions. Computer Standards & Interfaces, 50:76–82.

[34] Sheffer, Y. and Holz, R. (2015). Summarizing Known Attacks on Transport Layer Security(TLS) and Datagram TLS (DTLS) (RFC 7457). Internet Engineering Task Force (IETF).Available online in October 2017: https://tools.ietf.org/html/rfc7457.

[35] Springall, D., Durumeric, Z., and Halderman, J. A. (2016). Measuring the Security Harmof TLS Crypto Shortcuts. In Proceedings of the 2016 Internet Measurement Conference(IMC 2016), pages 33–47, Santa Monica. ACM.

[36] VanderSloot, B., Amann, J., Bernhard, M., Durumeric, Z., Bailey, M., and Halderman,J. A. (2016). Towards a Complete View of the Certificate Ecosystem. In Proceedings of the2016 Internet Measurement Conference (IMC 2016), pages 543–549, Santa Monica. ACM.

[37] Wander, M. (2017). Measurement Survey of Server-Side DNSSEC Adoption. In Proceed-ings of the Network Traffic Measurement and Analysis Conference (TMA 2017), pages 1–9,Dublin. IEEE.

[38] Wei, X. and Wolf, M. (2017). A Survey on HTTPS Implementation by Android Apps:Issues and Countermeasures. Applied Computing and Informatics, 13(2):101–117.

11