# Security of Alerting Authorities in the WWW:
Measuring Namespaces, DNSSEC, and Web PKI

Pouyan Fotouhi Tehrani  Weizenbaum Inst / Fraunhofer FOKUSBerlinGermany
<EMAIL_ADDRESS>,  Eric Osterweil  George Mason UniversityFairfaxVAUSA
<EMAIL_ADDRESS>,  Jochen H. Schiller  Freie Universität BerlinBerlinGermany
<EMAIL_ADDRESS>,  Thomas C. Schmidt  HAW HamburgHamburgGermany
<EMAIL_ADDRESS>and  Matthias Wählisch  Freie Universität
BerlinBerlinGermany<EMAIL_ADDRESS>
(2021)

###### Abstract.

During disasters, crisis, and emergencies the public relies on online services
provided by official authorities to receive timely alerts, trustworthy
information, and access to relief programs. It is therefore crucial for the
authorities to reduce risks when accessing their online services. This
includes catering to secure identification of service, secure resolution of
name to network service, and content security and privacy as a minimum base
for trustworthy communication.

In this paper, we take a first look at Alerting Authorities (AA) in the US and
investigate security measures related to trustworthy and secure communication.
We study the domain namespace structure, DNSSEC penetration, and web
certificates. We introduce an integrative threat model to better understand
whether and how the online presence and services of AAs are harmed. As an
illustrative example, we investigate 1,388 Alerting Authorities. We observe
partial heightened security relative to the global Internet trends, yet find
cause for concern as about 78% of service providers fail to deploy measures of
trustworthy service provision. Our analysis shows two major shortcomings.
First, how the DNS ecosystem is leveraged: about 50% of organizations do not
own their dedicated domain names and are dependent on others, 55% opt for
unrestricted-use namespaces, which simplifies phishing, and less than 4% of
unique AA domain names are secured by DNSSEC, which can lead to DNS poisoning
and possibly to certificate misissuance. Second, how Web PKI certificates are
utilized: 15% of all hosts provide none or invalid certificates, thus cannot
cater to confidentiality and data integrity, 64% of the hosts provide domain
validation certification that lack any identity information, and shared
certificates have gained on popularity, which leads to fate-sharing and can be
a cause for instability.

DNS, DNSSEC, Web PKI, Emergency Management

††journalyear: 2021††copyright: iw3c2w3††conference: Proceedings of the Web
Conference 2021; April 19–23, 2021; Ljubljana, Slovenia††booktitle:
Proceedings of the Web Conference 2021 (WWW ’21), April 19–23, 2021,
Ljubljana, Slovenia††doi: 10.1145/3442381.3450033††isbn:
978-1-4503-8312-7/21/04††ccs: Security and privacy Web application
security††ccs: Security and privacy Domain-specific security and privacy
architectures

5pt 0.8(0.1,0.02) If you cite this paper, please use the WWW reference: Pouyan
Fotouhi Tehrani, Eric Osterweil, Jochen H. Schiller, Thomas C. Schmidt, and
Matthias Wählisch. 2021. Security of Alerting Authorities in the WWW:
Measuring Namespaces, DNSSEC, and Web PKI. In _Proceedings of the Web
Conference 2021 (WWW ’21)_. ACM, New York, NY, USA, 12 pages.
https://doi.org/10.1145/3442381.3450033

##  1\. Introduction

Online media have been proven to be an effective channel to communicate with
the public. An ever growing number of Americans prefer to get their news
online (Geiger, 2019), social media is being used for public health
announcements (Tursunbayeva et al., 2017), and authorities provide public
disaster education and services via Web portals (FEMA, 2004)—just to mention a
few examples. Communication of critical information such as emergency response
(Arroyo Barrantes et al., 2009, Chapter 3) and provisioning of critical
services are no exception to this trend. Research shows that in emergencies
the public turns to official and authoritative sources especially when
specific, precise, and trustworthy information is requested (Condon and
Robinson, 2014; Endsley et al., 2014; Chauhan and Hughes, 2017). At the same
time, evaluating the credibility and trustworthines of online service
providers during an emergency or crisis poses a real challenge for users
(Manoj and Baker, 2007). A recent example to illustrate such situations is the
novel Coronavirus (SARS-CoV-2) pandemic and its outbreak in the US in early
2020: with government institutions and health authorities being perceived as
the most (social media being the least) trustworthy sources of information by
the public (Fischer, 2020; Reporter, 2020), alone in the first month of the
outbreak, nearly half a billion visits were registered on websites of Centers
for Diseases Control and Prevention (CDC) and the National Institutes of
Health (NIH) (Administration, 2020). Similarly, the high amount of visits on
state unemployment websites brought the operation of many of those sites to a
halt (Burke, 2020). The high demand for COVID-related online services took
place in parallel with an explosion of misinformation campaigns and fraudulent
services. Despite efforts from top tech companies (Shu and Schieber, 2020) the
overwhelming infodemic (WHO, 2020) continued to grow and prevail (Brennen et
al., 2020). This over-abundance of information posed serious challenges both
to politics and public health, and the growing number of individuals and
business relying on unemployment insurance and governmental relief programs
led to a boom in online fraud (Sophos Labs, 2020) with many falling prey to
such schemes.

Figure 1. Accessing data from an Alerting Authority

In this paper, we address the research blind spot of trustworthy and secure
Web-based emergency services. We systematically investigate the digital
representation of emergency and disaster management organizations in the U.S.
through the lens of the Domain Name System (DNS), its Security Extensions
(DNSSEC) (Arends et al., 2005a, c, b), _and_ the Web PKI (see Figure 1). Based
on our threat model, we aim to understand whether and how specific integration
of these organizations in the domain namespace and their use of DNSSEC and
X.509 certificates can mitigate threats against trustworthy communication. The
point of departure for our study is the list of Alerting Authorities (AA)
provided by FEMA (FEMA, 2020b), which comprises all entities (the US
governmental and non-governmental organizations) on federal, state,
territorial, tribal, and local levels authorized to dispatch alerts.

Our key finding shows that only about 22%, i.e., 291 out of a total 1327
unique hosts, provide sufficient measures to ensure trustworthy
identification. This decomposes as follow: (i) only half the investigated
organizations are uniquely identifiable based on dedicated domain names while
the rise of multitenancy structures and shared certificates throughout the
past decade has complicated identifications in general and has also led to an
expansion of attack surfaces (Osterweil et al., 2014), (ii) the majority of
organizations ($\approx 64\%$) do not take advantage of restricted namespaces
for better protection against name spoofing and more than 96% of investigated
DNS zones are susceptible to DNS attacks due to lack of DNSSEC, and finally
(iii) about 15% are exposed to content poisoning as a result of invalid or no
certificates. In more detail, in this paper we contribute:

  1. (1)

Threat model (Section 3). We introduce a threat model that integrates
different characteristics of DNS and Web PKI into groups of _Assurances
Profiles_ that qualifies various degrees of reachable security.

  2. (2)

Method (Section 4). Our method identifies common public Alerting Authorities
in the US and corresponding websites. The modular and configurable pipeline
introduced here for data collection and analysis maintains a certain level of
generality which makes it suitable to be extended to non-US regions in future
work.

  3. (3)

Analysis of namespace structure and protection (Section 5). We map names of
Alerting Authorities to fully qualified domain names (FQDN) and identify
operational dependencies. Usage of restricted and protected namespaces as well
as penetration of DNSSEC among AAs are investigated in this section. We also
studied whether there are discrepancies between organizations from various
fields of operation (e.g., governmental, military).

  4. (4)

Analysis of Web PKI (Section 6) We analyze Web PKI certificates used to
authenticate and identify Alerting Authorities. On the one hand the historical
and actual usage of X.509 are studied, and on the other hand it is
investigated how widespread these technologies are, which certificate
authorities are leading the market among AAs, and how (automated) domain-
validation certificates affect trustworthy communication.

While prior work has investigated the deployment of security protections
broadly across different application domains, to the best of our knowledge,
this is the first paper that investigates the security profiles of official
critical (and critical-to-life) Alerting Authorities. After presenting
background and our results, we discuss improving measures and conclude with an
outlook.

##  2\. Background

Emergency management (EM) can be understood as an ongoing cycle of mitigating,
preparing for, responding to, and recovering from incidents that threaten
life, property, operations, or the environment (Blanchard, 2008; Association
and Wixted, 2018). The core objectives of emergency management, ranging from
coordination efforts to raising awareness and critical service provision, are
carried out by governmental agencies, NGOs, volunteer groups, and
international organizations. The structure and organization of these entities
differ in each country and even on local and regional levels. In the US, the
list of Alerting Authorities regularly published by FEMA (FEMA, 2020b)
provides a non-exhaustive overview of organizations which are (directly or
indirectly) involved in the process of emergency management.

In each phase of EM cycle, communication (between and among authorities and
the public) plays an integral role not just as a mere necessity but also in
amounting to social resilience (Longstaff and Yang, 2008). Beside using
dedicated alerting systems, e.g., FEMA’s _Integrated Public Alert & Warning
System_ (FEMA, 2020a), social media, or similar channels for information
dissemination, many involved organizations have their own dedicated websites
not only for informational purposes but also for services such as volunteer
registry or disaster aid application (e.g., Homeland Security’s
disasterassistance.gov).

Table 1. Assurance profiles (● : strong, ◐ : weak, ○ : inadequate) based on the interplay of DNS and X.509 certificate characteristics (✓: deployed, ✘: not deployed) and security implications for users ( : fulfilled, : dependent protection, : inadequate). Note if OV or EV certification is deployed, then domain validation is covered and not further assessed (–). | DNS |  | Web PKI |  | Security Implications |  |  Assurance Profile
---|---|---|---|---|---|---|---
# | Restricted TLD | DNSSEC |  | DV | OV/EV |  | Identification | Resolution | Transaction |  Weakness
01 | ✓ | ✓ |  | – | ✓ |  |  |  |  |  N/A | ●
02 | ✓ | ✓ |  | ✓ | ✘ |  |  |  |  |  Ambiguous identification | ◐
[.4pt/3pt]03 | ✘ | ✓ |  | – | ✓ |  |  |  |  |  Possible impersonation through name spoofing | ◐
[.4pt/3pt]04 | ✓ | ✘ |  | – | ✓ |  |  |  |  |  DNS hijacking | ◐
[.4pt/3pt]05 | ✘ | ✘ |  | – | ✓ |  |  |  |  |  Name spoofing, DNS hijacking | ◐
06 | ✓ | ✘ |  | ✓ | ✘ |  |  |  |  |  DNS hijacking and ambiguous identification | ○
[.4pt/3pt]07 | ✘ | ✘ |  | ✓ | ✘ |  |  |  |  |  Impersonation and DNS hijacking | ○
[.4pt/3pt]08 | ✘ | ✓ |  | ✓ | ✘ |  |  |  |  |  Impersonation | ○
[.4pt/3pt]09 | ✓ | ✓ |  | ✘ | ✘ |  |  |  |  |  Content poisoning | ○
[.4pt/3pt]10 | ✓ | ✘ |  | ✘ | ✘ |  |  |  |  |  DNS hijacking, content poisoning | ○
[.4pt/3pt]11 | ✘ | ✓ |  | ✘ | ✘ |  |  |  |  |  Impersonation, content poisoning | ○
[.4pt/3pt]12 | ✘ | ✘ |  | ✘ | ✘ |  |  |  |  |  DNS hijacking, impersonation, content poisoning | ○

In this paper we investigate the namespace structure, DNSSEC penetration, and
deployment of Web PKI certificates among Alerting Authorities to maintain
secure communication (as defined in the next section). The global domain name
system (DNS), a distributed key-value database with a hierarchical namespace
and management scheme, is de facto the entry point to many (if not all) of
Internet services. Respectively, for critical service providers, e.g.,
Alerting Authorities, it is indispensable to be represented within namespaces
protected both in organizational and technical terms: top-level domains (TLD)
with restricted naming and delegation policies protect domain name owners
against name and trademark violations while assuring end users that the domain
name owner has undergone some form of vetting; at the same time, DNSSEC
(Arends et al., 2005a) compensates the vulnerable client/server paradigm of
DNS (Atkins and Austein, 2004) and caters for authenticated delegation and
protect DNS data against tampering. To authenticate the content provider
behind a domain name X.509 certificates (Cooper et al., 2008) are used. The
semantics of a certificate depends on its certification process: if the real-
world entity behind a certificate is vetted by a certification authority (CA)
and is respectively awarded with an organization or extended validation
certificate (OV/EV), the certificate can used for identification. Otherwise,
if the validation is limited to the ownership of a domain name, i.e., domain
validation (DV), the certificate is only good for authenticated
confidentiality and integrity.

##  3\. A Threat Model for Web-Based Emergency Communication

Emergency communication is dependent on heightened security requirements which
are not always as relevant for other Internet services (e.g., video streaming,
social media). Three steps constitute our definition of secure online
communication: (i) securely authenticating the authoritative service
(“identification” of the person, organization etc. behind the service name),
(ii) securely verifying that users have not been misdirected and are
transacting with the service name they have identified (“resolution” of name
to network service), and (iii) ensuring that the content was not altered,
leaks privacy etc. during the session (“transaction” security). Although
different methods can be utilized to realize such a secure workflow, here we
focus on those technologies that are most accessible to (and deployable by)
users and service operators in today’s Internet, namely the DNS and the Web
PKI ecosystems. Alternative solutions are discussed in Section 8.

##### An illustrative example

For illustration of the communication workflow and respective security
pitfalls, we consider the simple case of inquiring information about COVID-19
guidance as a resident of Jackson County in Missouri. Through a search engine,
an online ad, a recommendation from friends, etc. the URL is quickly
discovered: https://jacohd.org. When visiting the website, the presence of a
green padlock in the address bar indicates _only_ the confidentiality and
integrity of data exchange, but does not indicate whether the website belongs
to the supposed service (i.e., Health Department of Jackson County in Missouri
instead of one of the other 22 Jackson Counties). The generic domain name
could haven been registered and operated by anyone. An attacker could have
published a forged website implementing the look and feel of the real health
department. At no stage is the user given the chance to authenticate the
identity (i.e., identification) of the service provider because the provided
DV certificate does not include any identification information. In contrast,
the health department of Jackson County in Michigan is reachable under
www.co.jackson.mi.us111The complete URL is
https://www.co.jackson.mi.us/276/Health-Department.. Here, the domain name
under a restricted TLD indicates that it belongs to Jackson County
(co.jackson) in Michigan (mi.us), and the accompanying EV certificate serves
as a definitive proof of identity.

Figure 2. Toolchain to gather and analyze data about Alerting Authorities in
the US

##### Threaten identification

In a secure setting, it would be possible to identify and authenticate the
communication partner _before_ initiating the transaction. Yet, the point of
departure for Web communication are domain names, which cannot be used for
secure identification, while Web PKI certificates (as proofs of identity) are
provided only _after_ resolution succeeds and transaction is initiated. This
implies that targeting authentic names and subsequent secure resolution are
necessary (yet insufficient) conditions of identification through a
certificate. Respectively, simple name spoofing, e.g., through typosquatting
(Khan et al., 2015), DNS cache poisoning (Wang, 2015), or other DNS hijacking
attacks, which can mislead users to malicious services, can act as a precursor
for impersonation attacks, especially if subsequently only a DV certificate
with no identity information is presented. A viable countermeasure is the use
of restricted namespaces so at least the affiliation or identity of the
service provider can be inferred directly from its respective name.
Governmental organizations in the US, for example, educate visitors that
domain names of federal government agencies most commonly end in .gov or .mil.
Subsequently, an OV/EV certificate provides direct elements of proof of
identity. When considering using approaches like this, exceptions may serve to
help prove the rule: consider that the United States Post Office’s (USPO’s)
official website is uspo.com, i.e., not under .gov. This, then, necessitates
additional knowledge or verification before users of _that_ government agency
can be assured that they are transacting with the official authority online.
Proper identification, thus, involves both selection of proper domain names,
secure resolution (see below), and identity information from OV/EV
certificate.

##### Threaten resolution

The second attack surface pertains to name resolution. There are two methods
to assert that a name has been resolved correctly: either by using DNSSEC or
through the X.509 bindings in a certificate’s common name (CN) or subject
alternative names (SAN). The latter approach, however, provides only an a
posteriori assurance, i.e., after transaction initiation with a server, and
only if the resolution has already succeeded correctly. Furthermore,
especially in case of DV certificates, if resolution is compromised, e.g.,
through DNS poisoning, and as a result attackers were granted a DV certificate
(see Brandt  _et al._ (Brandt et al., 2018)), there is no way to verify the
integrity of the resolution process. The only effective solution in securing
name resolution and deterring collateral damages such as DV certificate
misissuances is deployment of DNSSEC.

##### Threaten transaction

In the final step, after name identification and resolution, it is imperative
to secure the transaction using transport security protocols (TLS/SSL) in
terms of authenticated confidentiality and integrity. It is worth noting that
authentication (using X.509 certificates) is crucial, because encryption and
integrity checks alone can also be performed by a malicious actor using
monkey-in-the-middle attacks.

##### Assurance profiles

Based on threats on the three aforementioned dimensions, Table 1 provides the
various combinations of DNS and Web PKI options and the security implications
of their deployment for users; the _Assurance Profiles_ summarizes their
combinations.

To achieve _strong assurance_ , a service provider should own a domain name
that (i) indicates its affiliation, (ii) is securely delegated, and (iii) is
bound with a real-world entity through an OV/EV certificate. A prominent
example is coronavirus.gov which is registered under .gov TLD denoting it
being a governmental domain name, supports DNSSEC (i.e., cannot be hijacked),
and provides a valid OV certificate belonging to the _Executive Office of the
President_.

A service provider that only partially covers these aspects and fails to
deploy DNSSEC or uses a name under a non-restricted namespace exhibits a _weak
Assurance Profile_ due to susceptibility to DNS hijacking or simple name
spoofing. This is how a campaign in Germany was able to defraud up to 4000
applicants of the corona relief program of a federal state. The scammers
spoofed the original domain name soforthilfe-corona.nrw.de by registering nrw-
corona-soforthilfe.de without much burden because the .de TLD has no
delegation restrictions that cannot be circumvented with minimal effort.
Although the authentic name (the former) was bound to a valid OV certificate,
the spoofed name was awarded with a DV certificate which gave the impression
of authenticity and caused users to fell prey to this phishing campaign.
Similarly, the threat of DNS hijacking was highlighted during the pandemic as
attackers managed to exploit a vulnerability in home routers and made use of
insecure DNS to manipulate name resolution; an attack which could easily be
defended through DNSSEC.

In contrast to the previous cases, _inadequate assurance_ reflects the case
when no certificate or only a DV certificate is provided _regardless_ of
domain name properties and presence of DNSSEC. Lack of a certificate at the
very least defeats the purpose of authenticated encryption and integrity
verification222Considering that alternative SSL/TLS authentication methods,
e.g., pre-shared keys, are not scalable and suitable for studied cases here.,
while a mere DV certificate can at best only cater to confidentiality and
integrity without providing any information about the identity of service
provider. An example of weak assurance is the Corona Emergency Response Fund
of CDC foundation under give4cdcf.org which have raised millions of dollars in
fighting the pandemic. The usage of .org generic TLD simplifies name
spoofing333At the time of writing give4cdcf.net remains undelegated., lack of
DNSSEC make it a suitable target for hijacking, and finally the provided DV
certificate practically doesn’t provide any evidence of identity.

Table 2. Top-level domains in use by Alerting Authorities

| TLD |  | Registration |  | Registry |  | Statistics
---|---|---|---|---|---|---|---
Type | Label | DNSSEC |  | Restricted | Fee/year |  |  Name | Country |  | Share | Count | DNSSEC
gTLD |  |  |  |  |  |  |  |  |  |  |  |

& ✓ ✘ ¡ 15 $ Verisign US 19.44 % 258 2 2-10[.4pt/3pt] .org ✓ ✘ ¡ 15 $ Public
Internet Registry US 26.15 % 347 5 2-10[.4pt/3pt] .net ✓ ✘ ¡ 15 $ Verisign US
4.37 % 58 0 2-10[.4pt/3pt] .info ✓ ✘ ¡ 15 $ Afilias US 0.15 % 2 0
2-10[.4pt/3pt] 50 % 665 7 ccTLD .cc ✓ ✘ ¡ 15 $ eNIC 1 US 0.07 % 1 0
2-10[.4pt/3pt] .co ✓ ✘ ¡ 20 $ .CO Internet S.A.S 2 US 0.07 % 1 0
2-10[.4pt/3pt] .us ✓ (✓) ¡ 15 $ Neustar US 4.89 % 65 0 2-10[.4pt/3pt] 5.04 %
67 0 ccSLD .<code>.us (✓) ✓ – Neustar US 17.71 % 235 2 sTLD .edu ✓ ✓ 77 $
Educase 3 US 0.45 % 6 0 2-10[.4pt/3pt] .gov ✓ ✓ 400 $ General Services
Administration US 25.92 % 344 30 2-10[.4pt/3pt] .mil ✓ ✓ – Defense Information
Systems Agency US 0.75 % 10 10 2-10[.4pt/3pt] 27.12 % 360 40 Unique domain
names 1327

1 subsidiary of Verisign, 2 subsidiary of Neustar, 3 operated by Verisign

##  4\. Method and Data Corpus

The subject of study in this paper are the US organizations involved in EM.
Due to lack of a central registry, we focus on the list of Alerting
Authorities maintained by FEMA. Although this list might not include each and
every entity involved in emergency management, it provides a decent,
legitimate overview over this field comprising a wide spectrum of
organizations ranging from local governments, law enforcement agencies, and
military bases to NGOs and universities. Each entry represents an organization
by a unique ID, a name, and a territory of operation (including unincorporated
territories). Throughout this study, we use the AA list from September 11,
2019 comprising 1,388 entries (excluding a single duplicate entry).

Our method consists of three phases: (1) preparation phase, (2) domain
namespace analysis, and (3) Web PKI analysis. Our measurements were carried
out from October 2019 up to March 2020 with each measurement being executed at
least twice from various vantage points in Europe and the US to detect any
possible vantage point dependent discrepancies, e.g., limited access due to
geo-blocking. Figure 2 summarizes our methodology from preparation phase to
data gathering and final analysis (see § 5 and § 6).

##### (1) Preparation

In the preparation phase, we first retrieve and parse the AA list and assign
the domain name used for web services for each organization. To identify the
primary website of an Alerting Authority, we query and scrape the Google
search engine. For each entry in the AA list, the combination of name and
territory of operation (e.g., Fresno Police Department CA) was used as query
string. Each query yielded between 4 and 12 results. Since the results are not
necessarily ranked to have the official URL first, we excluded results based
on a list of inapt domain names (e.g., social media sites and yellow pages).
The topmost remaining URL was then selected for the respective organization.
Finally, the list of collected URLs was manually checked to remove any
mismatches and falsely associated URLs which were not detected automatically,
e.g., same URL for homonymous counties in different states. A total of $23$
entries were removed: $11$ entries with mismatched names, $11$ associated with
the wrong territory of operation, and $1$ with no matching URL at all; leaving
a total of $1,365$ URLs for further analysis. The remaining URLs (e.g.,
https://www.fresno.gov/police) were parsed to extract the FQDNs (e.g.,
www.fresno.gov) and path segments (e.g., /police).

##### (2) Domain Namespace Analysis

In the second phase we first separate effective second-level domains (SLD)
from TLDs, e.g., for ‘www.ci.tracy.ca.us’, ‘ca.us’ being the TLD (more
specifically the public suffix) and ‘tracy’ the effective SLD. We then check
DNSSEC status for both the given domain name and its TLD, categorize TLDs
(restricted/unrestricted), and finally, based on a list of predefined keywords
(see Table A.I in Appendix) map each Alerting Authority to a _field of
activity_ as either Public safety, Governmental, Law enforcement, Military, or
Educational. The results of our analysis on domains names is presented in
Section 5.

##### (3) Web PKI Analysis

Finally, domain names were used to investigate the current and historic
adaption of Web PKI certificates by respective hosts. To study the current
state, OpenSSL version 1.1.1d CLI was leveraged to fetch complete certificate
chains, perform validation, and verify revocation status using stapled Online
Certificate Status Protocol (OCSP) (3rd, 2011), manual OCSP (Santesson et al.,
2013), or Certificate Revocation Lists (CRL) (Cooper et al., 2008) (depending
on availability). For our historical analysis, we used CT logs (Laurie et al.,
2013; Scheitle et al., 2018). To do this we leveraged the publicly accessible
database provided by Sectigo under crt.sh, which audits 79 log servers from 12
organizations (at the time of writing). For any given host name, the database
was queried for certificates which have the host name or a wildcard covering
the host name as their subject name or have it included in the list of subject
alternative names (SAN). From a total of $28,370$ retrieved unique
certificates, $10,826$ were pre-certificates and are omitted from further
analysis. The remaining $17,544$ certificates were then limited to those
issued in the past decade (2009-2019), leaving a total number of $17,477$
certificates which are analyzed as described in Section 6.

##  5\. DNS Namespace Analysis

By studying the domain names of alerting authorities, we aim to answer the
following questions:

  1. (1)

Does each AA have its own dedicated domain name?

  2. (2)

How do AAs integrate in the global DNS namespace?

  3. (3)

Do AAs secure their names using DNSSEC?

The first question is concerned with how Alerting Authorities maintain their
online presence, and avoid unnecessary dependencies. Lack of a dedicated name,
for example, leads to dependence on someone else for authentication and data
security as X.509 certificates are bound to domain names. The second question
aims to investigate whether AAs prefer specific TLDs to take advantages of
recognizability (e.g., governmental organization under .gov) and security
(restricted vs. non-restricted TLDs). Finally, the last question regards
measures taken in securing names against threats such as spoofing or DNS
hijacking which can also lead to impersonation and phishing. Section 3
summarizes our findings.

###  5.1. Dedicated Domain Names

We consider an AA to have a dedicated DNS name either if it has its own
effective SLD, or has been assigned a sub-domain under the namespace of its
parenting organization or any generic service provider, which is not shared.
For example, the Tehama County Sheriff (tehamaso.org) has its own dedicated
name whereas Apache County Sheriffs Office (www.co.apache.az.us/sheriff/) does
not.

To measure dedicated domain names we divided the set of AA URLs into two
groups depending on whether the URL path segment is empty (674 entries) or not
(691 entries); the group with empty path segments was then regarded as having
dedicated names. To prevent false positives of non-dedicated names, we
manually examined all these websites and verified that the landing page does
not relate to the Alerting Authority. We found only 25 false positives (e.g.,
http://www.franklincountyema.org/db/ with /db path being the start page),
which leads to overall $\approx$ 51% AAs with dedicated names while the rest
represents common names of parent organizations or other service providers. We
also observed three emergency management agencies with dedicated names which
are redirected (using HTTP 301/302 response codes) to web pages under county
or state websites. Out of the total 1,365 collected URLs 1,327 unique domain
names exist, showing that in some cases multiple entities are subsumed under
the same domain, e.g., different agencies all under the domain name of a
single state.

The data also shows that all educational entities (total of 4) and over 90% of
governmental entities (467 out of 503) such as state and local governments own
dedicated names in contrast to only $\approx$ 25% of public safety entities
(164 out of 669), and less than half of military organizations (8 out of 19)
which nearly all are represented under home.army.mil.

###  5.2. Namespace Structure

We start with various TLDs and country code second-level domains (ccSLDs) in
use by Alerting Authorities, which we group as follows:

gTLD (ICANNWiki, 2017b)::

generic top-level domain, e.g., .org

ccTLD (ICANNWiki, 2017a)::

country code top-level domain, e.g., .us

ccSLD (ICANNWiki, 2017c)::

country code second-level domain, e.g., .ny.us

sTLD (ICANNWiki, 2017d)::

sponsored top-level domain, e.g., .mil

Each TLD group features different properties. In general, there are little to
no delegation limits and naming conventions for names under gTLDs or ccTLDs
except for the .us namespace. Under .us ccTLD more than 3,000 names are
reserved and unavailable for public registration (Neustar, 2020) and the
namespace has a rigorous structure with domain names at second, third, or
fourth levels. This structuring reflects the “political geography” (Cooper and
Postel, 1993) and defines a number of reserved names for designated
organizations or purposes, e.g., county or city, and territory of operation
(Cooper and Postel, 1993; Neustar, Inc., [n.d.]). Finally, sponsored TLDs
(.edu, .gov, and .mil) impose stricter eligibility requirements and thus have
an advantage over gTLD names so that it can be made sure that only eligible
registrants are granted the ownership of respective domain names (Postel and
Reynolds, 1984; Federal Networking Council, 1997), given that such policies
are adequately enforced by respective registries.

As summarized in Section 3, whereas half of domain names are registered under
generic TLDs, the remaining majority ($\approx$ 45%) makes use of sponsored
TLDs and names within the .us state-code namespace, and the rest 5 percent
opts for domains under ccTLDs. It is noteworthy that the .us locality
namespace exhibits a relatively low penetration among AAs. For example, the
usage of canonical forms [ci,co].<locality>.<state-code>.us for cities or
counties: we observe that for every 5 cities which have the term city in their
domain names there exists only 1 city which uses the foreseen naming pattern,
and for every 4 counties choosing to have the term county in its domain name,
there is only one county opting for the canonical form.

Figure 3. Distribution of TLD types per operation territory

Finally, we examined if the specific choice of top-level domains for an
organization correlates with the organization’s field of operation. Figure 3
depicts how widespread various TLD types are in use in different fields of
operation. It is noteworthy that educational and military organizations make
exclusive use of restricted TLDs (.edu and .mil respectively), whereas gTLDs
remain the more popular choice among the others. This figure also confirms the
previous observations that the majority of remaining organizations, regardless
of field of operation, opt for generic TLDs instead of taking advantage of
special namespaces within the well-organized structured of .us namespace.

###  5.3. DNSSEC Deployment

Figure 4. Support for DNSSEC among .us ccSLDs in use

We used drill to chase DNS signatures and verify if a domain has properly
activated DNSSEC. All TLDs in use by AAs (see Section 3) support DNSSEC except
a number of .us ccSLD domains: out of 50 total state ccSLDs under .us
namespace, 32 have been used by AA organizations with only 18 supporting
DNSSEC. Figure 4 depicts the state ccSLDs, which support DNSSEC (blue), which
do not support (red), and those which are not used by any of organizations in
our data set (white).

Although $\approx$ 57% of TLDs in use support DNSSEC, less than 4% of AA
domain names have DNSSEC enabled. Compared with the longitudinal DNSSEC study
of Chung et al. (Chung et al., 2017a), measuring $0.6\%$ for .com and $1.0\%$
for .org domains, we observe a higher DNSSEC penetration. However, to our
surprise even among .gov SLDs which are mandated to implement DNSSEC (Office
of E-Government and Information Technology, 2009) less than 10% (30) have
support for DNSSEC which is considerably less than the $\approx 90\%$ DNSSEC
penetration among select governmental organizations (sample set of ca. 1200
.gov SLDs) as measured by NIST (NIST, 2020).

##  6\. Web PKI Analysis

The ecosystem of Web PKI revolves around X.509 certificates. We investigate
the deployment and characteristics of certificates in the context of Alerting
Authorities to answer the following questions:

  1. (1)

To what extent do AAs adapt web PKI?

  2. (2)

How is the historic landscape of X.509 shaped among AAs?

###  6.1. Current Deployment of Certificates

To have a better understanding of the current deployment of web certificates,
we gathered a snapshot of SSL/TLS deployment on public servers of Alerting
Authorities.

Out of the total 1327 unique names, 1187 hosts ($\approx$ 89%) support SSL/TLS
with 1130 hosts ($\approx$ 95%) delivering valid X.509 certificates. Within
the remaining 57 hosts, 17 use expired certificates, 9 use self-signed
certificates, and 1 has self-signed certificates in its certificate chain. The
validity of certificates provided by the remaining 30 hosts could not be
verified due to some kind of misconfiguration, e.g., use of invalid
certificates or certificates with missing issuer information. Recall that we
use OpenSSL trusted root certificates for validation. Compared with other Web
PKI studies we see in our focused sample of AA organizations relatively less
invalid certificates compared to global average of $65\%$ as observed by Chung
et al. (Chung et al., 2016) over the IPv4 space in 2016, or $\approx 13\%$ as
measured by Durumeric et al. (Durumeric et al., 2013) for Alexa 1M top domain
list in 2013.

Table 3. DNS and Web PKI alongside assurance profiles

DNS |  | Certificate |  |
---|---|---|---|---
Restricted delegation |  Supports DNSSEC |  | DV | O/EV |  Assurance profile1 | # Names
✓ | ✓ |  | – | ✓ |  ● |  29 ($\approx 2\%$)
✓ | ✓ |  | ✓ | ✘ |  ◐ | 11
[.4pt/3pt]✘ | ✓ |  | – | ✓ |  ◐ | 2
[.4pt/3pt]✓ | ✘ |  | – | ✓ |  ◐ | 132
[.4pt/3pt]✘ | ✘ |  | – | ✓ |  ◐ | 117
1-6[.4pt/3pt] Total: |  262 ($\approx 20\%$)
✓ | ✘ |  | ✓ | ✘ |  ○ | 354
[.4pt/3pt]✘ | ✘ |  | ✓ | ✘ |  ○ | 482
[.4pt/3pt]✘ | ✓ |  | ✓ | ✘ |  ○ | 3
[.4pt/3pt]✓ | ✓ |  | ✘ | ✘ |  ○ | 2
[.4pt/3pt]✓ | ✘ |  | ✘ | ✘ |  ○ | 67
[.4pt/3pt]✘ | ✓ |  | ✘ | ✘ |  ○ | 2
[.4pt/3pt]✘ | ✘ |  | ✘ | ✘ |  ○ | 126
1-6[.4pt/3pt] Total: |  1036 ($\approx 78\%$)
Grand Total: | 1327

1 ● strong, ◐ weak, ○ inadequate (see Table 1)

Table 4. Validation types and assurance profiles per sector

| Certificate |  |  Assurance profile1
---|---|---|---
Type | N/A | DV | OV | EV |  |  ● |  ◐ |  ○
Public Safety | 102 | 415 | 119 | 8 |  |  10 |  120 |  514
[.4pt/3pt]Governmental | 73 | 318 | 102 | 6 |  |  7 |  104 |  388
[.4pt/3pt]Law Enforcement | 21 | 110 | 31 | 0 |  |  5 |  28 |  129
[.4pt/3pt]Military | 1 | 4 | 5 | 1 |  |  6 |  3 |  2
[.4pt/3pt]Educational | 0 | 0 | 4 | 0 |  |  0 |  4 |  0
[.4pt/3pt]Other | 0 | 3 | 3 | 1 |  |  1 |  3 |  3
Total | 197 | 850 | 264 | 16 |  |  29 |  262 |  1036

1 ● strong, ◐ weak, ○ inadequate (see Table 1)

Section 6.1 combines our findings from this Section and Section 5 to reveal
different combinations of DNS and X.509 certificate characteristics, linked to
different levels of assurance according to Table 1. In Table 4, we group our
results by organization types. Due to low penetration of DNSSEC, popularity of
open TLDs, and pervasiveness of DV certificates among AAs (§ 5), only about
22% of AA are considered to be equipped against common threats to trustworthy
communication.

###  6.2. Historic X.509 Certificate Landscape

The historic analysis of X.509 certificates collected from Certificate
Transparency logs (see Section 4) helps us to gain a better understanding of
security policy changes related to Alerting Authorities and CAs. We span ten
years. It should be noted that the total number of organizations with publicly
logged certificates changes for each year. We consider this in the following
and normalize the results either with respect to the number of organizations
or total number of certificates valid per year.

####  6.2.1. Certificate Authorities

In addition to common regulations, certificate authorities implement and
follow their own set of policies. From the perspective of relying parties,
i.e., web users, such policies are opaque and as long as a CA is included in a
user’s trust store, it is considered trustworthy. For the subscribers,
however, these policies among other factors such as fees, offered certificate
types, and operation costs are decisive in choosing an appropriate CA.

We focus our analysis on the list of top CAs with an average coverage of
yearly 20 unique AA subscribers (hosts) in the last decade. We use the term
cover to differentiate from issuance: if a host, for example, is issued a
certificate by a CA valid from 2010 to 2013, we consider this host to be
covered by that CA for 2010, 2011, 2012, and 2013. Respectively, if a CA
issues multiple short-lived certificates (e.g., 90 days) for a host within a
given year, we only count that host as covered once in that year by the
issuing CA. This would avoid the data skew in favor of issuers with lower
certificate validity windows and higher certification rate per year. It also
should be noted that a single host can have certificates issued from different
CAs. Figure 5 depicts these findings in terms of relative market share
development in the past decade (see Table A.II in Appendix for details).
Compared with the CA market share for the Alexa 1M top domain list throughout
the last last decade (Holz et al., 2011; Durumeric et al., 2013; Aas et al.,
2019) we observe parallels, such as decline of GoDaddy’s market share and
rapid gains of Let’s Encrypt, as well as discrepancies that cannot directly be
explained due to dynamic nature of and fluctuations in the Alexa top list.

Figure 5 also highlights two factors evidently decisive for AAs in their
choice of CA: convenience and cost factors. GoDaddy, for example, which has
been the market leader among AAs for about two thirds of the past decade,
provides web hosting and domain name registration beside certification
services in convenient packages; and Let’s Encrypt, which has surged to the
top in the short period after its public offering, offers automated DV
certification at no cost.

Figure 5. Market share of top CAs in the past decade

####  6.2.2. Validation types and assurance profiles

(a) Certificate types

(b) Assurance profiles

Figure 6. Development of certificate types and assurance profiles (§3) in the
past decade

In Section 6.1, we showed that currently only about 22% of AAs honor security
profiles that are resilient against threats to trustworthy communication (see
Tables 6.1 and 4). Historically, however, as depicted in Figure 6, a higher
share of alerting authorities provisioned for such measures. When compared
with the share of various certificate validation types (DV, OV, and EV), it
becomes evident how the decreasing usage of OV certificates is directly
proportional to the reduction of preferred assurance profiles. At the same
time the surging popularity of DV certificates has led to an increase in cases
of what we consider as inadequately trustworthy (no identification). It should
be noted that as our partial historical DNSSEC penetration statistics
(collected through SecSpider444https://secspider.net (Osterweil et al.,
2014)), covering $\approx 25\%$ of studied hosts, exhibits negligible
fluctuation in DNSSEC penetration, we made a simple assumption that historic
support for DNSSEC among AAs equals to its current penetration state (see
Section 5.3).

####  6.2.3. Certificate Sharing

Except EV certificates, both DV and OV certificates allow wildcard names as
subject alternative names (SAN) to avoid enumerating all FQDNs under the
control of the certificate holder. In practice, the SAN extension also allows
sharing a certificate among different hosts. For example, In 2019 the federal
government was issued OV certificates with more than 600 SAN entries each.
Certificate sharing expands the attack surface and increases operational costs
since if one of the hosts is compromised or the certificate is revoked, every
other host also need to configured with a new certificate (sometimes called
“fate-sharing”).

Figure 7. Share of host names represented by certificates with more than 10
unique SAN entries

Multitenancy web hosting and security service providers (both public or
government exclusive) are making use of shared certificates as depicted in
Figure 7. It is worth noting that Let’s Encrypt certificates only allow up to
100 DNS type SANs. In our analysis, we also noticed an increasing number of
certificate sharing among hosts which _do not_ belong to the same logical
entity. Most critically also among OV certificates where a service provider
obtains a certificate under its name and lists the host name of its customers
as SAN, practically defeating the identification purpose of the certificate.
At the time of writing, for example, we observe cases of such certificates
listing SANs that obviously belong to separate entities, e.g., mo.gov,
asap.farm, and incapsula.com under the same certificate. In this very specific
case, records from the _Wayback Machine_ archives show that asap.farm has
previously belonged to Missouri Department of Agriculture (of Agriculture,
2018) but it was never removed from the certificate as the domain name
registration was transferred to another entity.

####  6.2.4. Certificate Validity

A certificate is presumed valid if, among others, it is deployed within its
validity period, is issued by a trustworthy CA, carries a valid signature, is
bound to the correct subject name, and is not revoked (see RFC 5280 (Cooper et
al., 2008)). Checking revocation status often requires network transactions,
and is the most expensive operation among aforementioned factors. Thus in many
cases it is either performed inadequately or ignored altogether by browsers
(partly in favor of proprietary solutions) (Liu et al., 2015). Consequently,
in the past years both CAs and browser vendors have been negotiating to cap
and reduce certificate lifetimes (Forum, 2017a, b, 2019) as an effort to
reduce security risks due to misissued or revoked certificates.

Figure 8. Validity distribution of logged certificates per year

As depicted in Figure 8, the lifetime of certificates utilized by AAs has been
constantly decreasing. This trend can partly be attributed to consensus among
CAs and browser vendors to reduce certificate lifetimes, but also due to
rising popularity of CAs which are specialized on free and automated DV
certificates such as Let’s Encrypt (fixed lifetime of 90 days). The median
validity periods that we observe here are comparable with related works
(Durumeric et al., 2013; Chung et al., 2016), yet there are no recent studies
that can corroborate the sharp decrease in validity periods from 2015 on.

##  7\. Related Work

To the best of our knowledge, this is the first study investigating how
Alerting Authorities in the US (as part of broader critical infrastructure)
implement measures to cater for trustworthy Web-based communication and
service provision. Previous research on trust in online emergency service
provision mainly focuses on form and content and its relation to the
perception of trustworthiness (Endsley et al., 2014; Busà et al., 2015; Hughes
and Chauhan, 2015), conception of trustworthy emergency communication and
collaboration systems (Büscher et al., 2009; Palen et al., 2010) or simply
best practices in building trust (Longstaff and Yang, 2008; Arroyo Barrantes
et al., 2009). Although previous research has already highlighted how knowing
who is behind an online emergency service impacts the trustworthiness of their
respective services (Paton, 2007; Longstaff and Yang, 2008; Endsley et al.,
2014), we observe a research gap when it comes to evaluating the measures at
one’s disposal to reach this goal. More specifically, the interplay of
characteristics of domain names and X.509 certificates, i.e., Assurance
Profile (Section 3). has not been investigated to our best knowledge.
Respectively, we limit ourselves to an overview of related work which studies
these technologies on their own.

##### Domain Namespace and DNSSEC

The influence of a domain name on authenticating or at least recognizing the
real-world entity behind that name has been investigated in terms of general
trustworthiness associated with TLDs and impersonation of trusted entities
through domain name masquerading. Walther, Wang, and Loh (Walther et al.,
2004) examine how choice of TLD can positively impact the credibility of
health websites. Seckler et al. (Seckler et al., 2015) investigate how a
relevant domain name, e.g., a known TLD, can positively enforce familiarity
and in turn increase trust. Similarly, a yearly report (for Good, 2018)
commissioned by the Public Internet Registry examines the trustworthiness of
select TLDs among NGO donors.

A closely related topic is how the domain namespace of malicious websites is
structured and operated. Korczynski et al. (Korczynski et al., 2018) show how
low pricing and registration barriers alongside the possibility of bulk
registration is an enabler for malicious actors to migrate to new gTLDs. In a
longitudinal study of typosquatting, Agten et al. (Agten et al., 2015) reveals
how registration fees and registry policies can attract or deter malicious
actors; practically determining the credibility of such TLDs (the top three
most abused TLDs in the world are new gTLDs (Project, 2020)). And Antonakakis
et al. (Antonakakis et al., 2010) introduce a reputation system for DNS to
detect malicious domain names. Different studies show how scammers try to
impersonate other entities by partly or fully integrating legitimate domain
names in their own domain names (Agten et al., 2015; Kintis et al., 2017; Tian
et al., 2018; Roberts et al., 2019) or even by using homonymous names using
internationalized domain names (Suzuki et al., 2019).

With regard to namespace security, studies in the past pinpoint a relatively
low DNSSEC penetration due to various factors ranging from lack of support by
local resolvers to server misconfigurations (Osterweil et al., 2008; Hao Yang
et al., 2011; Lian et al., 2013; Chung et al., 2017a) despite more than 90% of
all TLDs being signed and supporting DNSSEC (Research, 2020). The prevalence
of DNSSEC among various types of organizations, such as educational, military,
commercial, etc. has not been subject of study to determine if there is a
correlation between field of operation and sensibility for DNS security
measures. The only exception is the fine-grained, i.e., including second level
domains, regular analysis of DNSSEC deployment among select governmental
agencies within the .gov namespace, educational institutions, and industry in
the US (NIST, 2020; Rose, 2012).

##### Web PKI

Throughout the years, various measurements have characterized X.509
certificates in use over the Internet in terms of validity, issuing CAs, key
strength, etc. (Mishari et al., 2009; Holz et al., 2011; Durumeric et al.,
2013; Chung et al., 2016). Among these, Mishari et al. (Mishari et al., 2009)
investigate the difference between certificates of legitimate and fraudulent
websites. The study by Holz et al. (Holz et al., 2011) has the advantage of
being performed from different vantage points spread over the world. The
measurements by Durumeric et al. (Durumeric et al., 2013) is noteworthy as it
goes beyond mere X.509 certificate analysis and investigates the dependencies
among root and intermediate CAs, their market share, and the characteristics
of respective certificates. And finally, the measurements performed by Chung
et al. (Chung et al., 2016) aim to understand why a majority of certificates
advertised over IPv4 are invalid. It should be noted that except the last
study, the others have been carried out before major changes in the Web PKI
occurred, such as various mergers and the public launch of Let’s Encrypt (Aas
et al., 2019). Furthermore, the findings from these studies exhibit different
characteristics of sample sets, which are either too limited (e.g., Alexa Top
1M) or too broad (e.g., IPv4 space). Those differences do not allow for
statistical inference and comparison with our observations.

In a recent study, which is most closely related to our work, Singanamalla et
al. (Singanamalla et al., 2020) measure the adoption of https at government
websites. Using primarily an automated, keyword-based matching to collect
domain names this approach is prone to false positives and makes comparison to
our work infeasible. Also, this work does not relate to Assurance Profiles,
which we introduce in our study.

Specifically related to the topic of our work are studies which investigate
the trustworthiness of CAs in general and their policies specially in enabling
fraud and impersonation. Delignat-Lavaud et al. (Delignat-Lavaud et al.,
2014), for example, investigate the conformance of CAs to the CA/Browser Forum
guidelines, which in turn can influence trustworthiness of a CA. Others have
defined various metrics to qualify (Chadwick and Basden, 2001; Fadai et al.,
2015) or quantify trustworthiness of CAs (Heinl et al., 2019) beyond technical
measures. In a recent study Schwittmann, Wander and Weis (Schwittmann et al.,
2019), similar to Brandt et al. (Brandt et al., 2018), exhibit how various CAs
are susceptible to attacks on DV certification processes that can practically
lead to domain impersonation. Roberts et al. (Roberts et al., 2019) studies
which CAs are responsible for issuing DV certificates to malicious target-
embedded domains.

##  8\. Key Findings and Discussions

Our results draw a rather alarming picture of the current online emergency
management landscape regarding trustworthy communication. Along the line of
our key findings, we discuss the possible reasons for the observed
deficiencies and suggest alternatives.

##### Only about 22% of AAs deploy sufficient identification

Identification, as discussed in Section 3, succeeds over multiple factors,
which are only insufficiently attended to by AAs: only about half of AAs have
their dedicated names and as such cannot obtain exclusive X.509 certificates
as proof of identity (as these are bound to domain names) while a majority of
$\approx 78\%$ fail to provide any valid certificate or just DV certificates
which lack identification information. The majority of organizations opt for
generic TLDs which simplifies name spoofing and phishing as precursors of
impersonation. Additionally, the minuscule penetration rate of DNSSEC provides
another attack surface by poisoning DNS records and misdirecting users to
malicious websites. Alerting Authorities should at best be located under
restricted namespaces as an additional factor of recognizably and assurance,
have at least their own subdomains instead of being subsumed in the path
segment of a URL, secure their namespace using DNSSEC, and provide OV/EV
certificates as definitive proof of identity.

##### Less than 4% of AAs offer secure name resolution

Securing domain names is seemingly a non-priority for investigated
organizations as the low penetration rate of DNSSEC suggests. Insecure DNS not
only can cause misdirection from authentic websites, but also DV certificate
misissuance (Brandt et al., 2018; Schwittmann et al., 2019) which impacts both
identification and session security. Although DNSSEC suffers low deployment on
the global scale in general, it is an indispensable component in securing
emergency communication as part of the broader critical infrastructure. Yet,
it should be noted that in some cases due to lack of support registrants are
forced to abandon DNSSEC in favor of other factors, e.g., registering under a
.us locality name for which there is, surprisingly, no DNSSEC support (see
Figure 4). We also note that although domain names under .gov namespaces are
mandated to use DNSSEC (Office of E-Government and Information Technology,
2009), the low support for DNSSEC has its roots in operational and
organizational mismanagement rather than technical issues.

##### DV certificates dominate transaction security

The popularity of domain validation certificates combined with low penetration
of DNSSEC represents an attack surface that can compromise session security
through certificate missisuance and monkey-in-the-middle attacks. If DV is
indispensable for some, we encourage the stakeholders to reconsider
semantically equivalent alternative of TLSA domain issued certificates (DANE
EE) as they provide higher resilience against spoofing in contrast to DV
certificates (Schwittmann et al., 2019). In general, DANE can be used to
remove ambiguity regarding public keys and responsible CAs for a domain name
(Osterweil et al., 2014).

##### Fate-sharing is on the rise

The lack of dedicated domain names and an increase of certificate sharing in
multitenancy settings represents worrisome and de facto unnecessary
dependencies, which both can expand the attack surface (Osterweil et al.,
2014) and can cause instabilities in the future. Regarding shared
certificates, we suggest abandoning them completely and also encourage CAs to
avoid issuing OV certificates for service providers without ensuring that all
the listed subject alternative names belong to the same organization.

##### Convenience and cost impact security preferences

We observe 15% of AAs providing none or invalid certificates. This can be
traced back to carelessness regarding the Web PKI trust model (self-signed
certificates) or additional (not only financial) configuration (Krombholz et
al., 2017) and certification costs. Rapid growth of Let’s Encrypt with its
fully automated certificate issuance and renewal is an indication of how the
aforementioned factors influence the decision for choosing an appropriate CA.
Similarly, we measure less than 45% represented under restricted namespaces.
In contrast to gTLDs, higher registration fees or bureaucratic hurdles, and
longer delegation processing times are among discouraging factors, which call
for governmental support and can effectively be addressed by policy-makers
through price caps and easier access for eligible organizations which fulfill
the strict requirements.

##### Responsibilities beyond Alerting Authorities

The scope of trustworthy communication goes beyond our investigations and
extends to consumers as well as infrastructure operators such as CAs, ISPs,
and browser vendors. There is still a gap between CA practices and guidelines
(Delignat-Lavaud et al., 2014), some automated DV certification services are
susceptible to impersonation attacks (Schwittmann et al., 2019; Roberts et
al., 2019), and some root CAs do not restrict certification scope for their
intermediate CAs (Durumeric et al., 2013). DNS registrars not always offer
DNSSEC by default or free of cost (Chung et al., 2017b) and only a minority of
ISPs bother to operate DNSSEC-aware recursive resolvers that properly verify
signed DNS records (Wander and Weis, 2013; Chung et al., 2017a). Browser
vendors should also provide better security usability by avoiding confusing
SSL/TLS warnings (Akhawe and Felt, 2013), improve instead of abandoning visual
cues for different certificate types (Felt et al., 2019; O’Brien, 2019;
Hofmann, 2019), and start offering alternative CA trustworthiness assessment
measures beyond the standard binary trust model (Chadwick and Basden, 2001;
Fadai et al., 2015; Heinl et al., 2019). Finally, users should be educated in
better understanding the semantics of domain names (Roberts et al., 2020) and
web PKI certificates and their practical use and ramifications.

##  9\. Conclusion and Outlook

In this paper, we conceptualized a threat model for trustworthy communication
in emergency management and analyzed the lack of common technologies, DNS(SEC)
and Web PKI, to mitigate threats to identification, resolution, and content
manipulation or eavesdropping. We provided an overview of how Alerting
Authorities (AA) in the US are structured within the domain namespace, how
widespread is DNSSEC in securing their domain names, and how Web PKI is used
for authentication and data security. We uncovered deficiencies and discussed
alternatives while emphasizing that respective solutions are not necessarily
technical but operational as well as political. Protecting critical
infrastructure for emergency communication and public safety entails
addressing operational and policy challenges on national and international
levels and calls for commitment of all stakeholders from service providers to
intermediate infrastructure operators and browser vendors alongside policy-
makers.

In the future, this work can be extended beyond the US territory while
providing a comparison basis for other countries. Furthermore, other
technologies can be accommodated in our assurance profiles. Finally, the role
of intermediate infrastructure and further dependency structures can be
investigated in depth.

##### Data Disclosure

We provide a browser that presents the assurance profile of each Alerting
Authority and additional accompanying material on https://aa.secnow.net. Our
toolchain and collected data are published under doi:10.5281/zenodo.4300946.

##### Ethical Considerations

We informed Alerting Authorities about their assurance profiles to raise
awareness for improvements.

##### Acknowledgments

This work was supported in parts by the German Federal Ministry of Education
and Research (BMBF) within the project _Deutsches Internet-Institut_ (grant
no. 16DII111).

## References

  * (1)
  * 3rd (2011) D. Eastlake 3rd. 2011\.  _Transport Layer Security (TLS) Extensions: Extension Definitions_.  RFC 6066. IETF.
  * Aas et al. (2019) Josh Aas, Eric Rescorla, Seth Schoen, Brad Warren, Richard Barnes, Benton Case, Zakir Durumeric, Peter Eckersley, Alan Flores-López, J Alex Halderman, Jacob Hoffman-Andrews, and James Kasten. 2019.  Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web. In _Proc. of the 2019 ACM SIGSAC CCS_. ACM Press, New York, NY, USA, 2473–2487.
  * Administration (2020) U.S. General Services Administration. 2020\.  Digital Analytics Program.  https://analytics.usa.gov/
  * Agten et al. (2015) Pieter Agten, Wouter Joosen, Frank Piessens, and Nick Nikiforakis. 2015.  Seven Months’ Worth of Mistakes: A Longitudinal Study of Typosquatting Abuse. In _Proc. of the 2015 NDSS_. Internet Society, Reston, VA, USA, 8–11.
  * Akhawe and Felt (2013) Devdatta Akhawe and Adrienne Porter Felt. 2013.  Alice in warningland: A large-scale field study of browser security warning effectiveness. In _Proc. of 22nd USENIX Security Symposium_. USENIX Association, 257–272.
  * Antonakakis et al. (2010) Manos Antonakakis, Roberto Perdisci, David Dagon, Wenke Lee, and Nick Feamster. 2010.  Building a dynamic reputation system for DNS. In _Proc. of the 19th USENIX Security Symposium_. USENIX Association, 273–289.
  * Arends et al. (2005a) R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. 2005a.  _DNS Security Introduction and Requirements_.  RFC 4033. IETF.
  * Arends et al. (2005b) R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. 2005b.  _Protocol Modifications for the DNS Security Extensions_.  RFC 4035. IETF.
  * Arends et al. (2005c) R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. 2005c.  _Resource Records for the DNS Security Extensions_.  RFC 4034. IETF.
  * Arroyo Barrantes et al. (2009) Susana Arroyo Barrantes, Martha Rodriguez, and Ricardo Pérez (Eds.). 2009.  _Information Management and Communication in Emergencies and Disasters_.  Pan American Health Organization, Washington D.C., USA.
  * Association and Wixted (2018) National Fire Protection Association and M.T. Wixted. 2018.  _NFPA 1600, Standard on Continuity, Emergency, and Crisis Management, 2019 Edition_.  National Fire Protection Association, Quincy, MA, USA.
  * Atkins and Austein (2004) D. Atkins and R. Austein. 2004.  _Threat Analysis of the Domain Name System (DNS)_.  RFC 3833. IETF.
  * Blanchard (2008) B. Wayne Blanchard. 2008\.  Guide To Emergency Management and Related Terms, Definitions, Concepts, Acronyms, Organizations, Programs, Guidance, Executive Orders & Legislation.  , 1366 pages.
  * Brandt et al. (2018) Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, and Michael Waidner. 2018.  Domain Validation++ For MitM-Resilient PKI. In _Proc. of the 2018 ACM SIGSAC_. ACM Press, New York, NY, USA, 2060–2076.
  * Brennen et al. (2020) J. Scott Brennen, Felix Simon, Philip N. Howard, and Rasmus Kleis Nielsen. 2020.  Types, sources, and claims of COVID-19 misinformation.  https://reutersinstitute.politics.ox.ac.uk/types-sources-and-claims-covid-19-misinformation
  * Burke (2020) Minyvonne Burke. 2020\.  Coronavirus: State unemployment websites crash as applications surge.  https://www.nbcnews.com/news/us-news/coronavirus-state-unemployment-websites-crash-applications-surge-n1162731
  * Busà et al. (2015) Maria Grazia Busà, Maria Teresa Musacchio, Shane Finan, and Cilian Fennel Stillwater. 2015\.  Trust-building through social media communications in disaster management. In _Companion Proc. of the 24th ACM WWW_. ACM, New York, NY, USA, 1179–1184.
  * Büscher et al. (2009) Monika Büscher, Preben Holst Mogensen, and Margit Kristensen. 2009.  When and How (Not) to Trust It? Supporting Virtual Emergency Teamwork.  _International Journal of Information Systems for Crisis Response and Management_ 1, 2 (apr 2009), 1–15.
  * Chadwick and Basden (2001) David W. Chadwick and Andrew Basden. 2001.  Evaluating trust in a public key certification authority.  _Computers and Security_ 20, 7 (2001), 592–611.
  * Chauhan and Hughes (2017) Apoorva Chauhan and Amanda Lee Hughes. 2017.  Providing Online Crisis Information. In _Proc. of the 2017 CHI_. ACM Press, New York, NY, USA, 3151–3162.
  * Chung et al. (2016) Taejoong Chung, Yabing Liu, David Choffnes, Dave Levin, Bruce MacDowell Maggs, Alan Mislove, and Christo Wilson. 2016.  Measuring and Applying Invalid SSL Certificates: The Silent Majority. In _Proc. of the ACM IMC ’16_. ACM Press, New York, NY, USA, 527–541.
  * Chung et al. (2017a) Taejoong Chung, Roland Van Rijswijk-Deij, Balakrishnan Chandrasekaran, David Choffnes, Dave Levin, Bruce M. Maggs, Alan Mislove, and Christo Wilson. 2017a.  A longitudinal, end-to-end view of the DNSSEC ecosystem. In _Proc. of the 26th USENIX Security Symposium_. USENIX Association, 1307–1322.
  * Chung et al. (2017b) Taejoong Chung, Roland van Rijswijk-Deij, David Choffnes, Dave Levin, Bruce M. Maggs, Alan Mislove, and Christo Wilson. 2017b.  Understanding the Role of Registrars in DNSSEC Deployment. In _Proc. of the ACM IMC ’17_. ACM, New York, NY, USA, 369–383.
  * Condon and Robinson (2014) Sherri L. Condon and Jason R. Robinson. 2014.  Communication media use in emergency response management. In _ISCRAM 2014 Conference Proceedings_. ISCRAM, 687–696.
  * Cooper and Postel (1993) A. Cooper and J. Postel. 1993.  _The US Domain_.  RFC 1480. IETF.
  * Cooper et al. (2008) D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, and W. Polk. 2008\.  _Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile_.  RFC 5280. IETF.
  * Delignat-Lavaud et al. (2014) Antoine Delignat-Lavaud, Martín Abadi, Andrew Birrell, Ilya Mironov, Ted Wobber, and Yinglian Xie. 2014.  Web PKI: Closing the Gap between Guidelines and Practices. In _Proc. of the 2014 NDSS_. Internet Society, Reston, VA, USA, 23–26.
  * Durumeric et al. (2013) Zakir Durumeric, James Kasten, Michael Bailey, and J. Alex Halderman. 2013.  Analysis of the HTTPS certificate ecosystem. In _Proc. of the ACM IMC ’13_. ACM Press, 291–304.
  * Endsley et al. (2014) Tristan Endsley, Yu Wu, and James Reep. 2014.  The source of the story: Evaluating the credibility of crisis information sources.  _ISCRAM 2014 Conference Proceedings_ 1, 1 (2014), 160–164.
  * Fadai et al. (2015) Tariq Fadai, Sebastian Schrittwieser, Peter Kieseberg, and Martin Mulazzani. 2015.  Trust Me, I’m a Root CA! Analyzing SSL Root CAs in Modern Browsers and Operating Systems. In _Proc. of the 2015 10th ARES_. IEEE Press, 174–179.
  * Federal Networking Council (1997) Federal Networking Council. 1997\.  _U.S. Government Internet Domain Names_.  RFC 2146. IETF.
  * Felt et al. (2019) Adrienne Porter Felt, Robert W. Reeder, Alex Ainslie, Helen Harris, Max Walker, Christopher Thompson, Mustafa Emre Acer, Elisabeth Morant, and Sunny Consolvo. 2019\.  Rethinking connection security indicators. In _Proc. of 12th SOUPS_. USENIX Association, 1–14.
  * FEMA (2004) FEMA. 2004.  Are you ready? An In-depth Guide to Citizen Preparedness.
  * FEMA (2020a) FEMA. 2020a.  Integrated Public Alert & Warning System.  https://www.fema.gov/integrated-public-alert-warning-system
  * FEMA (2020b) FEMA. 2020b.  Organizations with Alerting Authority Complete and In Process.  https://www.fema.gov/media-library/assets/documents/117152
  * Fischer (2020) Sara Fischer. 2020\.  Media wrestles with public trust as coronavirus intensifies.  https://www.axios.com/media-public-trust-coronavirus-da69dd7f-4b8a-4793-ac52-dc1ed2c3e35f.html
  * for Good (2018) Nonprofit Tech for Good. 2018\.  2018 Global Trends in Giving Report.  https://givingreport.ngo/
  * Forum (2017a) CA/Browser Forum. 2017a.  Ballot 185 – Limiting the Lifetime of Certificates.  https://cabforum.org/2017/02/24/ballot-185-limiting-lifetime-certificates/
  * Forum (2017b) CA/Browser Forum. 2017b.  Ballot 193 – 825-day Certificate Lifetimes.  https://cabforum.org/2017/03/17/ballot-193-825-day-certificate-lifetimes/
  * Forum (2019) CA/Browser Forum. 2019\.  Ballot SC22 – Reduce Certificate Lifetimes (v2).  https://cabforum.org/2019/09/10/ballot-sc22-reduce-certificate-lifetimes-v2/
  * Geiger (2019) Abigail W. Geiger. 2019\.  Key findings about the online news landscape in America.  https://pewrsr.ch/34CNdu3
  * Hao Yang et al. (2011) Hao Yang, Eric Osterweil, Dan Massey, Songwu Lu, and Lixia Zhang. 2011.  Deploying Cryptography in Internet-Scale Systems: A Case Study on DNSSEC.  _IEEE Transactions on Dependable and Secure Computing_ 8, 5 (sep 2011), 656–669.
  * Heinl et al. (2019) Michael P. Heinl, Alexander Giehl, Norbert Wiedermann, Sven Plaga, and Frank Kargl. 2019\.  MERCAT: A Metric for the Evaluation and Reconsideration of Certificate Authority Trustworthiness. In _Proc. of the 2019 ACM SIGSAC CCSW_. ACM Press, New York, NY, USA, 1–15.
  * Hofmann (2019) Johann Hofmann. 2019\.  Intent to Ship: Move Extended Validation Information out of the URL bar.  https://groups.google.com/d/msg/firefox-dev/6wAg_PpnlY4/C_DCyZm9AQAJ
  * Holz et al. (2011) Ralph Holz, Lothar Braun, Nils Kammenhuber, and Georg Carle. 2011\.  The SSL landscape – A Thorough Analysis of the X.509 PKI Using Active and Passive Measurement. In _Proc. of the ACM IMC ’11_. ACM Press, New York, NY, USA, 427.
  * Hughes and Chauhan (2015) Amanda Lee Hughes and Apoorva Chauhan. 2015.  Online media as a means to affect public trust in emergency responders.  _ISCRAM 2015 Conference Proceedings_ (2015), 182–192.
  * ICANNWiki (2017a) ICANNWiki. 2017a.  Country code TLD.  https://icannwiki.org/ccTLD
  * ICANNWiki (2017b) ICANNWiki. 2017b.  Generic TLD.  https://icannwiki.org/GTLD
  * ICANNWiki (2017c) ICANNWiki. 2017c.  SLD.  https://icannwiki.org/SLD
  * ICANNWiki (2017d) ICANNWiki. 2017d.  STLD.  https://icannwiki.org/STLD
  * Khan et al. (2015) Mohammad Taha Khan, Xiang Huo, Zhou Li, and Chris Kanich. 2015\.  Every second counts: Quantifying the negative externalities of cybercrime via typosquatting. In _2015 IEEE Symposium on Security and Privacy_. IEEE, 135–150.
  * Kintis et al. (2017) Panagiotis Kintis, Najmeh Miramirkhani, Charles Lever, Yizheng Chen, Rosa Romero-Gómez, Nikolaos Pitropakis, Nick Nikiforakis, and Manos Antonakakis. 2017.  Hiding in Plain Sight: A Longitudinal Study of Combosquatting Abuse. In _Proc. of the 2017 ACM SIGSAC CCS_. ACM Press, New York, NY, USA, 569–586.
  * Korczynski et al. (2018) Maciej Korczynski, Maarten Wullink, Samaneh Tajalizadehkhoob, Giovane C. M. Moura, Arman Noroozian, Drew Bagley, and Cristian Hesselman. 2018\.  Cybercrime After the Sunrise: A Statistical Analysis of DNS Abuse in New GTLDs. In _Proc. of the 2018 ACM ASIACCS_. ACM, New York, NY, USA, 609–623.
  * Krombholz et al. (2017) Katharina Krombholz, Wilfried Mayer, Martin Schmiedecker, and Edgar Weippl. 2017.  “I have no idea what I’m doing” – on the usability of deploying HTTPS. In _Proc. of the 26th USENIX Security Symposium_. USENIX Association, 1339–1356.
  * Laurie et al. (2013) B. Laurie, A. Langley, and E. Kasper. 2013.  _Certificate Transparency_.  RFC 6962. IETF.
  * Lian et al. (2013) Wilson Lian, Eric Rescorla, Hovav Shacham, and Stefan Savage. 2013.  Measuring the practical impact of DNSSEC deployment. In _Proc. of the 22nd USENIX Security Symposium_. USENIX Association, 573–587.
  * Liu et al. (2015) Yabing Liu, Will Tome, Liang Zhang, David Choffnes, Dave Levin, Bruce Maggs, Alan Mislove, Aaron Schulman, and Christo Wilson. 2015.  An End-to-End Measurement of Certificate Revocation in the Web’s PKI. In _Proc. of the ACM IMC ’15_. ACM Press, New York, NY, USA, 183–196.
  * Longstaff and Yang (2008) P H Longstaff and Sung-Un Yang. 2008.  Communication Management and Trust: Their Role in Building Resilience to “Surprises” Such As Natural Disasters, Pandemic Flu, and Terrorism.  _Ecology and Society_ 13, 1 (2008), 1–14.
  * Manoj and Baker (2007) B.S. Manoj and Alexandra Hubenko Baker. 2007.  Communication challenges in emergency response.  _Commun. ACM_ 50, 3 (March 2007), 51–53.
  * Mishari et al. (2009) Mishari Al Mishari, Emiliano De Cristofaro, Karim El Defrawy, and Gene Tsudik. 2009\.  Harvesting SSL Certificate Data to Identify Web-Fraud.  _International Journal of Network Security_ 14, 6 (September 2009), 324–338.
  * Neustar (2020) Neustar. 2020.  Frequently Asked Questions about the .US Domain.  https://www.about.us/faqs
  * Neustar, Inc. ([n.d.]) Neustar, Inc. [n.d.].  .US Compliance Report.  https://ns-cdn.neustar.biz/creative_services/biz/neustar/www/resources/domain-names/us-locality-compliance-report.pdf
  * NIST (2020) NIST. 2020.  Estimating USG IPv6 & DNSSEC External Service Deployment Status.  https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov
  * O’Brien (2019) Devon O’Brien. 2019\.  Upcoming Change to Chrome’s Identity Indicators.  https://groups.google.com/a/chromium.org/d/msg/security-dev/h1bTcoTpfeI/jUTk1z7VAAAJ
  * of Agriculture (2018) Missouri Department of Agriculture. 2018\.  Missouri Agricultural Stewardship Assurance Program.  https://web.archive.org/web/20180107233724/https://asap.farm/
  * Office of E-Government and Information Technology (2009) Office of E-Government and Information Technology. 2009.  Securing the Federal Government’s Domain Name System Infrastructure.  , 3 pages.
  * Osterweil et al. (2014) Eric Osterweil, Danny McPherson, and Lixia Zhang. 2014\.  The shape and size of threats: Defining a networked system’s attack surface. In _2014 IEEE 22nd ICNP_. IEEE, 636–641.
  * Osterweil et al. (2008) Eric Osterweil, Michael Ryan, Dan Massey, and Lixia Zhang. 2008\.  Quantifying the Operational Status of the DNSSEC Deployment. In _Proc. of the ACM IMC ’08_. ACM Press, New York, NY, USA, 231–242.
  * Palen et al. (2010) Leysia Palen, Kenneth M. Anderson, Gloria Mark, James Martin, Douglas Sicker, Martha Palmer, and Dirk Grunwald. 2010.  A Vision for Technology-Mediated Support for Public Participation & Assistance in Mass Emergencies & Disasters. In _Proc. of the 2010 ACM-BCS_. BCS Learning & Development Ltd., Swindon, GBR, Article 8, 12 pages.
  * Paton (2007) Douglas Paton. 2007\.  Preparing for natural hazards: The role of community trust.  _Disaster Prevention and Management_ 16, 3 (2007), 370–379.
  * Postel and Reynolds (1984) J. Postel and J.K. Reynolds. 1984.  _Domain requirements_.  RFC 920. IETF.
  * Project (2020) Spamhaus Project. 2020\.  The World’s Most Abused TLDs.  https://www.spamhaus.org/statistics/tlds/
  * Reporter (2020) Morning Consult/The Hollywood Reporter. 2020\.  National Tracking Poll #200342 – Crosstabulation Results.  https://morningconsult.com/wp-content/uploads/2020/03/200342_crosstabs_HOLLYWOOD_Adults_v2_JB-1.pdf
  * Research (2020) ICANN Research. 2020\.  TLD DNSSEC Report.  http://stats.research.icann.org/dns/tld_report/
  * Roberts et al. (2019) Richard Roberts, Yaelle Goldschlag, Rachel Walter, Taejoong Chung, Alan Mislove, and Dave Levin. 2019\.  You Are Who You Appear to Be: A Longitudinal Study of Domain Impersonation in TLS Certificates. In _Proc. of the 2019 ACM SIGSAC CCS_. ACM Press, New York, NY, USA, 2489–2504.
  * Roberts et al. (2020) Richard Roberts, Daniela Lulli, Abolee Raut, Kelsey Fulton, and Dave Levin Levin. 2020.  Mental Models of Domain Names and URLs. In _Proc. of SOUPS_. USENIX Association, 5.
  * Rose (2012) Scott Rose. 2012\.  Progress of DNS Security Deployment in the Federal Government. In _Proc. of the 26th LISA_. USENIX Association, 223–228.
  * Santesson et al. (2013) S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams. 2013\.  _X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP_.  RFC 6960. IETF.
  * Scheitle et al. (2018) Quirin Scheitle, Oliver Gasser, Theodor Nolte, Johanna Amann, Lexi Brent, Georg Carle, Ralph Holz, Thomas C. Schmidt, and Matthias Wählisch. 2018.  The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem. In _Proc. of the ACM IMC ’18_. ACM Press, New York, NY, USA, 343–349.
  * Schwittmann et al. (2019) L. Schwittmann, M. Wander, and T. Weis. 2019\.  Domain Impersonation is Feasible: A Study of CA Domain Validation Vulnerabilities. In _2019 IEEE European Symposium on Security and Privacy (EuroS &P)_. IEEE Press, 544–559.
  * Seckler et al. (2015) Mirjam Seckler, Silvia Heinz, Seamus Forde, Alexandre N. Tuch, and Klaus Opwis. 2015.  Trust and distrust on the web: User experiences and website characteristics.  _Computers in Human Behavior_ 45 (2015), 39–50.
  * Shu and Schieber (2020) Catherine Shu and Jonathan Schieber. 2020.  Facebook, Reddit, Google, LinkedIn, Microsoft, Twitter and YouTube issue joint statement on misinformation.  https://tcrn.ch/2xJXrg8
  * Singanamalla et al. (2020) Sudheesh Singanamalla, Esther Han Beol Jang, Richard Anderson, Tadayoshi Kohno, and Kurtis Heimerl. 2020\.  Accept the Risk and Continue: Measuring the Long Tail of Government https Adoption. In _Proc. of the ACM IMC ’20_. ACM, New York, NY, USA, 577–597.
  * Sophos Labs (2020) Sophos Labs. 2020\.  Facing down the myriad threats tied to COVID-19.  https://news.sophos.com/en-us/2020/04/14/covidmalware/
  * Suzuki et al. (2019) Hiroaki Suzuki, Daiki Chiba, Yoshiro Yoneya, Tatsuya Mori, and Shigeki Goto. 2019.  ShamFinder: An Automated Framework for Detecting IDN Homographs. In _Proc. of the ACM IMC ’19_. ACM Press, New York, NY, USA, 449–462.
  * Tian et al. (2018) Ke Tian, Steve T. K. Jan, Hang Hu, Danfeng Yao, and Gang Wang. 2018.  Needle in a Haystack: Tracking Down Elite Phishing Domains in the Wild. In _Proc. of the ACM IMC ’18_. ACM Press, New York, NY, USA, 429–442.
  * Tursunbayeva et al. (2017) Aizhan Tursunbayeva, Massimo Franco, and Claudia Pagliari. 2017\.  Use of social media for e-Government in the public health sector: A systematic review of published studies.  _Government Information Quarterly_ 34, 2 (apr 2017), 270–282.
  * Walther et al. (2004) Joseph B. Walther, Zuoming Wang, and Tracy Loh. 2004.  The effect of top-level domains and advertisements on health web-site credibility.  _Journal of Medical Internet Research_ 6, 3 (2004), 1–11.
  * Wander and Weis (2013) Matthäus Wander and Torben Weis. 2013.  Measuring Occurrence of DNSSEC Validation. In _Passive and Active Measurement_ , Matthew Roughan and Rocky Chang (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 125–134.
  * Wang (2015) Zheng Wang. 2015\.  A revisit of DNS Kaminsky cache poisoning attacks. In _2015 IEEE GLOBECOM_. IEEE, 1–6.
  * WHO (2020) WHO. 2020.  Novel Coronavirus (2019-nCoV) Situation Report - 13.  https://apps.who.int/iris/handle/10665/330778

## Appendix

Table A.I. Regular expressions applied on an AA name to categorize its field of operation (in order of application). Category |  Regular expression
---|---
Military |  [^[:alnum:]]fort|^fort|army|missile|base|pfpa
[.4pt/3pt]Governmental |  county|counties|city|commission|borough|town|village|parish| authority|council| government|national|aviation|correction
[.4pt/3pt]Educational |  university
[.4pt/3pt]Law Enforcement |  police|sheriff|investigation|patrol|intelligence|’homeland security’|’law enforcement’
[.4pt/3pt]Public Safety |  911|’9-1-1’|emergency|ema|eom|ohsep|fire|safety| communication|dispatch
Table A.II. Count of unique hosts with at least one publicly logged
certificate per issuer for popular CAs. The last row shows the sum of unique
host for all observed CAs.

| Year
---|---
CA | ’09 | ’10 | ’11 | ’12 | ’13 | ’14 | ’15 | ’16 | ’17 | ’18 | ’19
Comodo$\dagger$ | 3 | 7 | 15 | 21 | 29 | 38 | 62 | 92 | 238 | 304 | 299
[.4pt/3pt]DigiCert | 31 | 53 | 70 | 83 | 92 | 105 | 120 | 133 | 146 | 263 | 281
[.4pt/3pt]Entrust | 7 | 13 | 22 | 25 | 34 | 32 | 33 | 39 | 40 | 44 | 48
[.4pt/3pt]GeoTrust$\ddagger$ | 0 | 5 | 29 | 49 | 54 | 59 | 63 | 67 | 68 | 61 | 29
[.4pt/3pt]GoDaddy | 25 | 54 | 80 | 109 | 141 | 183 | 215 | 249 | 290 | 330 | 347
[.4pt/3pt]LetsEncrypt$\dagger\dagger$ | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 29 | 102 | 210 | 335
[.4pt/3pt]Sectigo | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 228
[.4pt/3pt]Verisign$\ddagger$ | 18 | 45 | 49 | 43 | 43 | 42 | 35 | 27 | 17 | 6 | 0
All observed CAs | 122 | 244 | 298 | 356 | 398 | 458 | 517 | 630 | 830 | 1012 | 1109

$\dagger$ Rebranded to Sectigo in 2018. $\ddagger$ Acquired by DigiCert in
2017. $\dagger\dagger$ Beta in 2015; public in 2016.


# A Low-Power 1 Gb/s Line Driver with Configurable Pre-Emphasis for Lossy
Transmission Lines

N. St. John,11footnotetext: Corresponding author. S. Mandal  G. W. Deptuch  E.
Raguzin  S. Rescia

###### Abstract

A line driver with configurable pre-emphasis is implemented in a 65 nm CMOS
process. The driver utilizes a three-tap feed-forward equalization (FFE)
architecture. The relative delays between the taps are selectable in
increments of 1/16th of the unit interval (UI) via an 8-stage delay-locked
loop (DLL) and digital interpolator. It is also possible to control the output
amplitude and source impedance for each tap via a programmable array of eight
source-series terminated (SST) drivers. The entire design consumes 9 mW from a
1.2 V supply at 1 Gb/s.

##  1 Introduction

Modern front-end ASICs require line drivers to send the digitized measurement
data off-chip. Such line drivers must be optimized for the specific
transmission line (i.e., cable) used by the system to ensure a low bit error
rate (BER) while also minimizing power consumption. Furthermore, as data rates
continue to increase, transmission line effects (signal attenuation and
reflections) begin to hamper the performance of the data link. In particular,
attenuation generally increases with frequency, resulting a transfer function
(TF) for the transmission line that is low-pass in nature, while reflections
give rise to sharp maxima/minima at particular frequencies due to wave
interference. In order for transmitters to counteract the frequency-dependent
attenuation of the cable, which generates pulse distortion and inter-symbol
interference (ISI) in the time domain, designers often utilize a technique
known as pre-emphasis or feed-forward equaliaztion (FFE) [1].

Pre-emphasis is a technique in which the BER for a given data rate can be
improved via controlled pre-distortion of the output data signal, in
particular by adding overshoot (“emphasis”) around data transitions [2]. This
process adds high-frequency components to the signal. Ideally, one would want
to have an output waveform with a TF that is the inverse of the cable in order
to completely cancel the low-pass TF of the cable over a desired frequency
range.

Pre-emphasis is implemented via an $N$-tap finite impulse response (FIR)
filter as shown in Fig. 1(a). The example shown in the figure uses three taps
($N=3$) with programmable inter-tap delays, $\tau_{i}$, and tap weights,
$c_{i}$. The resulting continuous-time transfer function is given by
$H(f)=c_{0}+\sum_{i=1}^{N}{c_{i}\exp\left(-i2\pi
f\sum_{j=1}^{i}{\tau_{j}}\right)}$ and should have a high-pass response.
Conventional FFE implementations constrain the delays to
$\tau_{i}=1/f_{clk}=1\times UI$ where $f_{clk}$ is the clock frequency and
$1/f_{clk}$ is the unit interval (UI) [3]. In this case, $H(f)$ is periodic
with a period of $f_{clk}$, so the desired high-pass response is only obtained
over a limited frequency range (up to $1/(2f_{clk})$). In addition, the output
voltage swing is limited by power supply headroom, so the FFE coefficients
must be normalized such that $\sum_{i=0}^{N}|c_{i}|=1$. Thus, adding extra
taps may not significantly improve performance because the weights of the
other taps must decrease to satisfy the headroom constraint, which limits the
peak gain. Additionally, the shunt capacitance of the driver increases
approximately linearly with the number of taps, thus reducing its output
bandwidth. Thus, we restrict ourselves to a three-tap design ($N=3$). In
addition, we relax the constraint that all the $\tau_{i}$’s are equal to
$1\times UI$, thus allowing for greater flexibility in synthesizing the
desired TF over a broad frequency range. This property is particularly useful
in compensating for the attenuation of high-loss cables, such as radio-pure
microstrip lines on flexible TaiflexTM substrates developed for the nEXO
experiment.

The generic shape of the FFE output waveform is shown in Fig. 1(b). The weight
and duration of the first tap (known as preTap) and the third tap (known as
postTap) define the amount of pre-emphasis and are optimized to minimize BER
(i.e., maximize the eye opening) for a given cable and data rate. As an
example, we used electromagnetic simulations to extract a broadband model of a
3 m long radio-pure cable. The results, which are shown in Fig. 1(c), reveal a
loss of $-7$ dB/m at 1 GHz. The FFE was optimized to cancel this frequency-
dependent channel loss over a bandwidth of 1.5 GHz, which is adequate for our
assumed data rate of 0.5 Gb/s (i.e., $UI=2$ ns). The equalized TF, which is
also shown in the figure, is nearly flat over this bandwidth, as desired. By
contrast, note that a conventional FFE (with delays limited to $1\times UI$)
would only be able to equalize the TF up to a frequency of $0.5/UI=0.25$ GHz.

(a)

(b)

(c)

Figure 1: (a) Block diagram of the FFE architecture. (b) General pre-
emphasized output waveform. (c) Simulated TF of a 3 m length of radio-pure
planar transmission line on a flexible TaiflexTM substrate compared with the
power spectrum of random digital data at 0.5 Gb/s. The optimized TF of a
three-tap FFE and the resulting equalized TF of the channel are also shown.

The rest of this paper is organized as follows. The architecture of the line
driver is described in Section 2. Section 3 discusses the scheme used to
optimize the output waveform, while Section 4 describes a test chip designed
in a 65 nm process. Section 5 discusses both simulated and experimental
results of the optimized line driver design, while Section 6 concludes the
paper.

##  2 Circuit Design

A block diagram of the line driver is shown in Fig. 2. The design consists of
two main parts, namely the tap duration control and tap weight control
circuits. These work in tandem to generate the proposed fully-configurable
output waveform and are discussed below.

Figure 2: (a) Block diagram of the proposed line driver. (b) Schematic of an
SST driver with configurable source resistance; three arrays of such drivers
are used to generate the output waveform.

Tap Duration Control Circuitry: We utilize a multi-tap delay-locked loop (DLL)
to generate user-configurable tap durations that are robust to process,
voltage, and temperature (PVT) variations. Specifically, we use an 8-stage DLL
with a standard architecture consisting of a phase-frequency detector (PFD),
charge pump (CP), and voltage-controlled delay line (VCDL). A capacitive load
at the output of the CP creates a control voltage, $V_{c}$, that stabilizes
upon locking of the DLL. A novel single-test false lock detector also monitors
the DLL to ensure proper operation, as discussed later. The control voltage
$V_{c}$ then feeds two standalone 8-stage replica VCDLs that generate the
delays of the main and post-cursor taps. Each creates eight delayed copies of
its input waveform with relative delays equal to those of the stages in the
main VCDL. The delayed data waveforms then feed a single-stage digital
interpolator (DI) [4] that allows the user to interpolate between adjacent
taps, thus increasing the timing resolution by $2\times$. Thus, there are 16
uniformly-spaced relative delay options for each tap, resulting in a
resolution of $UI/16$. Finally, a buffer that accounts for the delay of the DI
inputs the system data and outputs the pre-cursor tap. This concept of
delaying the data rather than re-timing it via flip-flops is ideal for high-
speed design as it does not require power-hungry high-speed flip-flops.
Furthermore, the use of replica VCDLs allows designers to easily add
additional taps by daisy-chaining them, as we have done here.

False Lock Detector: The DLL includes a false lock detector (FLD) circuit that
can determine if the final tap is locked to a delay that is not equal to
$1\times UI$. This is crucial since if the DLL does not lock correctly, it
will degrade the granularity of relative delay options available to the user.
While important, the FLD only needs to be run once the system locks. However,
earlier FLD designs run continuously, thus wasting power [5]. For this reason,
we used the novel one-shot FDL algorithm shown in Fig. 3(a). When run on our
8-stage VCDL, this algorithm compares the relative delays of taps 1-4 and tap
8. Two checks need to be performed during the test, one to determine if there
is locking at integer multiples of the UI greater than 1, and another to
determine if there is locking at a non-integer multiple of the UI. For the
first check, we compare taps 1-4. If the DLL locked correctly, tap 4 would
have the maximum relative delay of this set. Therefore, from tap 1 to tap 4,
the delay between the tap output and the input clock should increase. If the
DLL locks at an integer multiple of the UI greater than 1, the delay will not
increase continuously from tap 1 to tap 4. Therefore, we compare the delays of
$tap[i]$ and $tap[i+1]$ for $i=\\{1,2,3\\}$. If any of these comparisons
result in $tap[i]$ having a greater or equal rising-edge delay to $tap[i+1]$,
then the test fails. If all tests pass, then a final check is performed to
detect non-integer locking. This is found by comparing taps 4 and 8. The delay
between the final tap and the input clock (modulo $1\times UI$) is ideally
zero after locking. However, if the DLL locks on a non-integer value, the
delay will be greatest at the final tap. Therefore, we compare taps 4 and 8:
if the delay is greater at tap 8, there is a failure, while if the opposite is
true the test passes. After detecting a pass or fail, the block shuts down
unless initiated to run again by the system, thus conserving power. At the
hardware level, the FLD was implemented using a set of modified phase detector
(PD) and CP circuits and static logic.

---

(a)

(c)

---

(b)

Figure 3: (a) Flowchart of the single-shot false-lock detection (FLD)
algorithm. (b) Simulated eye diagrams for data transmission at 1 Gb/s through
3 m of radio-pure cable. Top: with default parameter values; bottom: with
optimized parameter values. (c) Block diagram of the MATALB-Cadence co-
simulation procedure developed for automated optimization of line driver
parameters.

Tap Weight Control Circuitry: Configurable tap weights require control over
the drive strength of each tap output. Voltage-mode source-series terminated
(SST) driver arrays [6] are used for this purpose. SST drivers are chosen
instead of current-mode logic (CML) drivers as they consume 2-$4\times$ less
power for the same output swing. Eight parallel SST slices are provided for
each of the three taps, and the user can enable any number of slices per tap.
Lastly, three different source resistance options are provided, namely 300,
700, and 1100 $\Omega$. This additional flexibility allows one to either
improve output impedance matching or maximize/minimize output swing as needed.
The schematic of a single SST slice with configurable source resistance is
shown in Fig. 2(b).

##  3 Output Waveform Optimization

An automated process was developed for finding the optimum pre-emphasis
waveform for a given cable (in this case, the same 3 m long radio-pure cable
discussed in Section 1). As shown in Fig. 3(b), the eye diagram can be
significantly improved (relative to a conventional FFE with all tap delays
equal to $1\times UI$) by also optimizing the tap durations. While this
optimum was found via an exhaustive search, a more efficient procedure is
essential due to the large amount of available parameter permutations. To this
end, we developed a Cadence test bench that contains a Verilog-A model of the
line driver and a transistor-level model of the SST arrays driving the chosen
cable. This test bench outputs results into MATLAB via a Simulink model and a
SpectreRF coupler block that enables bidirectional communication between
MATLAB and Cadence using TCP/UDP packets. These results are then fed to a
MATLAB optimization function that minimizes a cost function given by
$FOM={\sqrt{I_{av}}}/{(e_{H}\times e_{W})},$ where $I_{av}$ is the average
power consumption of the driver and $e_{H}$ and $e_{W}$ are the height and
width of the eye opening with random input data, respectively. These
parameters are combined into a single Figure of Merit (FOM) that is designed
to favor a reasonable compromise between power consumption (proportional to
$I_{av}$) and BER (strongly decreasing with $e_{H}$ and $e_{W}$). Fig. 3(c)
illustrates the entire co-simulation and optimization flow.

##  4 Test Structure and Results

Fig. 4(a) shows a die photograph of the fabricated test chip, which integrates
the line driver with various clocking and data generation options and an I2C
control interface. The line driver core occupies $355\times 363$ $\mu$m. Total
power consumption varies from 4-9 mW while the maximum data rate is limited to
1 Gb/s by the DLL design. The design is compared with other work [7, 8, 9, 10]
in Fig. 4(b), which shows that our work maximizes user configurability while
minimizing power.

(a)

(b)

Figure 4: (a) Labeled die photograph of the test chip, which has a total area
of 1 mm2. (b) Comparison of line driver performance with comparable designs in
the literature.

##  5 Conclusion

We have described a highly-configurable line driver circuit in 65 nm CMOS that
is particularly suitable for driving high-loss channels. The circuit uses a
3-tap FFE with fine-grained control over both tap weights and time delays,
thus allowing the user to adapt the output waveform for a variety of cable
types and data rates. Future work will focus on i) higher data-rate
implementations, ii) replacing the existing DLL with an all-digital version,
and iii) implementing self-monitoring algorithms to enable the driver to
autonomously optimize its performance over time.

## References

  * [1] J.F. Bulzacchelli, _Equalization for electrical links: current design techniques and future directions_ , _IEEE Solid-State Circuits Magazine_ 7 (2015) 23.
  * [2] J.L. Casall, _Driver pre-emphasis for data transmission_ , Ph.D. thesis, Texas Tech University, 2001.
  * [3] Y. Fu, Z. Wen and L. Chen, _A 3.75Gb/s CML output driver with configurable pre-emphasis in 65nm CMOS technology_ , in _Proceedings of the 2nd International Conference on Communication and Information Processing_ , ICCIP ’16, (New York, NY, USA), p. 200–205, Association for Computing Machinery, 2016, DOI.
  * [4] B.W. Garlepp, K.S. Donnelly, J. Kim, P.S. Chau, J.L. Zerbe, C. Huang et al., _A portable digital DLL for high-speed CMOS interface circuits_ , _IEEE Journal of Solid-State Circuits_ 34 (1999) 632.
  * [5] B. Razavi, _A circuit for all seasons: The delay-locked loop_ , _IEEE Solid-State Circuits Magazine_ 10 (2018) 9–15.
  * [6] C. Menolfi, T. Toifl, P. Buchmann, M. Kossel, T. Morf, J. Weiss et al., _A 16Gb/s source-series terminated transmitter in 65nm CMOS SOI_ , in _2007 IEEE International Solid-State Circuits Conference. Digest of Technical Papers_ , pp. 446–614, IEEE, 2007.
  * [7] V. Gromov, V. Zivkovic, M. van Beuzekom, X. Llopart, T. Poikela, J. Buytaert et al., _Development of a low power 5.12 Gbps data serializer and wireline transmitter circuit for the VeloPix chip_ , _Journal of Instrumentation_ 10 (2015) C01054.
  * [8] K. Iniewski, V. Axelrad, A. Shibkov, A. Balasinski, S. Magierowski, R. Dlugosz et al., _3.125 Gb/s power efficient line driver with 2-level pre-emphasis and 2 kV HBM ESD protection_ , in _2005 IEEE International Symposium on Circuits and Systems (ISCAS)_ , pp. 1154–1157, IEEE, 2005.
  * [9] K. Huang, Z. Wang, X. Zheng, C. Zhang and Z. Wang, _A 80 mW 40 Gb/s transmitter with automatic serializing time window search and 2-tap pre-emphasis in 65 nm CMOS technology_ , _IEEE Transactions on Circuits and Systems I: Regular Papers_ 62 (2015) 1441.
  * [10] P. Moreira, S. Baron, S. Biereigel, J. Carvalho, B. Faes, M. Firlej et al., _lpGBT documentation: release_ (Mar, 2022).