- RSS
- Contact
-
How to Leverage an fTLD Domain:
TECHNICAL GUIDE TO SECURITY REQUIREMENTS
TABLE OF CONTENTS
Introduction
fTLD Registry Services’ (“fTLD”) Technical Guide to Security Requirements (the “Requirements”) is designed for technical staff and third-party providers of financial organizations and provides guidance on implementing the Requirements for a .BANK or .INSURANCE domain name (collectively “fTLD Domain”). This guide describes the Requirements that must be deployed by registrants (organizations that register domain names) and registrars (entities authorized by fTLD to offer fTLD Domains) in order to comply with the Requirements and fully benefit from their fTLD Domains.
The Requirements, accessible at ftld.com/security, have two components:
fTLD has compiled a list of publicly available, free resources that can be helpful in understanding whether the implementation of an fTLD Domain addresses the defined Requirements, and it’s available at ftld.com/domaincheck. Although these resources are useful, they are not the basis for fTLD’s Requirements monitoring service and are not exact checks against the Requirements.
Why the Additional Requirements?
An fTLD Domain is a trusted, verified, more secure and easily identifiable location on the internet for the global banking and insurance communities and the customers and stakeholders they serve. fTLD Domains have been designed and built by the international banking and insurance communities specifically for banks, insurers (inclusive of providers and distributors) and others in the financial services sector. Owned, operated and governed by the financial community, an fTLD Domain is where organizations can:
Requirements may need to change to meet the evolving landscape of risks and threats on the internet. fTLD intends that its Requirements—and likewise this guide—will change to stay ahead of the threats it is designed to mitigate.
DIGITAL ASSERTION AND VERIFIED DIGITAL IDENTITY
What is Digital Assertion?
Digital assertion is a process by which a network service (“verifier”) authenticates a user and generates an assertion about the result of the authentication to another network service that relies on that authentication to determine if services should be provided. Digital assertion allows for an individual or organization to assert its identity, have a means to prove that identity, involve a trusted organization to authenticate that identity and then assert that identity to gain access to an authenticated session. Often the assertion is a time-based token that acts as a credential for access to network systems.
What is the fTLD Domain Security Requirement for Digital Assertion?
Registration Authorities must establish digital assertion, or
an equivalent process, during the registration process.
In particular, Registration Authorities (i.e., registry operator and registrars) must provide an adequate description of their requirement for digital assertion, or equivalent process using best current practices, and how it will be applied to registrars and registrants.
How Does Digital Assertion and Verified Digital Identity Work?
While the internet was originally designed with a model of anonymity for its transactions, this is not appropriate in an fTLD Domain environment. Identity management involves establishing who is using a service and digital assertion and verified digital identity are techniques to enhance the level of trust in knowing who is using it.
Digital Identity Management
The fTLD Domain requirement mandates a strong approach to authentication. This is crucial in an fTLD Domain environment as a recent study highlighted that nearly 82 percent of cybercrime incidents targeted user credentials.
It’s critical to understand that the digital identity management requirements affect registry
operator-registrar and registrar-registrant interactions. Interactions with customers are not affected by this requirement.
One approach to improving on the common, but not robust, username and password combinations that are so familiar, is to introduce a second factor into the authentication process. Common approaches include a registration and verification component, the issuing of credentials and then options for a second-factor to be introduced. Thus, the user would possess the credentials provided after registration and, for the purpose of authentication a second-factor would be required. Examples of second-factors are:
In this approach, the two factors are often referred to as “something you have and something you know.”
A typical example is an authentication token that displays a time-limited random number. The combination of the personal information and the number displayed on the token constitute the two factors. Including two elements makes it more difficult for an unauthorized person to access the account because they would be required to know the personal information and have the access token as well.
According to research, multi-factor authentication2 can drastically reduce the incidence of online theft and other network-based fraud because access or theft of a password alone is not enough to gain access to online services or information.
Digital Identity and Digital Assertion Deployment for Registry Operator and Registrants
The fTLD Domain requirement does not specify a particular technology or methodology for meeting the digital assertion condition, but does provide that it must meet National Institute of Standards and Technology (NIST) level three or better. To meet the requirement, the registration authorities must
provide an adequate description of their policy for digital assertion or an equivalent process. The policy should use best current practices and describe how itwill be applied to registrars and registrants.
Such a policy must contain a description of:
While some in the registry/registrar environment have already developed a digital identity approach, it may be new to others. Multi-factor authentication is becoming easier to implement. In addition, multi-factor authentication (especially the second-authentication factor) is becoming easier to outsource. Network equipment vendors, telecommunication providers and specialist digital identity management companies have emerged in this product space and offer solutions that can be integrated with existing registration/credential granting systems.
DNSSEC
What is DNSSEC?
The original design of the DNS was almost completely focused on data availability and did not include a security component. Fundamentally, DNSSEC solves two crucial problems related to the DNS:
Adds a data integrity check to the DNS; and
Adds the capability to authenticate the trust chain of data provided by the DNS.
DNSSEC also provides a platform for future security technologies.
DNSSEC is a backward-compatible technology that extends the DNS by providing origin authentication of DNS data, data integrity and, where needed, authenticated denial of existence of domain name and resource records.
It is important to understand that DNSSEC does not solve every security problem related to the DNS. DNSSEC does not provide confidentiality of DNS responses or communications between DNS clients and servers. It also does not prevent attacks on DNS servers using other parts of the network stack—for instance, implementation of DNSSEC does not protect against Distributed Denial of Service (DDoS) attacks. As any organization may be targeted by malicious actors using a DDoS attack, it is advisable that their security plan, and that of their DNS provider, include a DDoS mitigation plan. Despite some of the drawbacks, DNSSEC ensures users are not hijacked en route to their intended destination and thereby builds trust and confidence to users conducting online activities.
What is the fTLD Domain Security Requirement for DNSSEC?
DNSSEC with strong cryptographic algorithms must be deployed at each zone and subsequent
sub-zones for domains that resolve in the DNS.
Registrars must communicate the DNSSEC requirement to their Registrants in their Registration Agreements and store Registrant’s DNSSEC records. Registrars must support DNSSEC and registrants must deploy DNSSEC with strong cryptographic algorithms for each domain and subdomain name that resolves in the DNS.
How Does DNSSEC Work?
DNSSEC uses public key cryptography to authenticate domain names and verify the integrity of traffic to and from those names. The internet relies on the ability of people and computers interacting at a distance. A customer may not have ever seen or met the principals of an internet business, but they still have to be able to exchange information with them. How does that customer know that the information sent from the business is legitimate and not an imposter?
In the real world there are many physical clues and cues that guide the application of trust to transactions, however most of these are simply not available on the internet.
One of the keys to building private and reliable communications between people, businesses and organizations on the internet is to use cryptography. Many types of cryptography are in use in the public internet, but DNSSEC uses a very specific type: public key cryptography.
DNSSEC allows a user to make a traditional query about an address and by using a combination of typical DNS queries and the addition of verifiable trust, ensure that the server answering the query is authoritative and the response to the query has not been tampered with during transmission. This is illustrated below for www.example.bank.
Public Key Cryptography
Public key cryptography is a secure, easy-to-deploy method for ensuring that messages and transactions can be changed into a form that can only be read by the intended recipient.
Each person, business or organization gets two “keys.” One, the “public key” is given to all possible recipients and made public. The other, the “private key,” is kept secret and in the hands of the sender. Messages encrypted with the “public” key can only be decrypted with the matching private key and messages encrypted with the “private” key can only be decrypted with the “public” key. When sending a message it is encrypted using the public key of the recipient. Given the only person who can decrypt the message is the person who has the matching private key, it doesn’t matter if another party intercepts the message. Even if someone could intercept or get a copy of the encrypted message, they could not decode as they would not have the matching private key.
Public key cryptography has wide use in technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Pretty Good Privacy (PGP) and Virtual Private Networks (VPNs) as a strategy for protecting messages on the internet.
Digital Signatures
One of the features of public key cryptography that is of special importance is digital signatures. Simply put, if a private key is used to generate a signature of a document or encrypt a message, the recipient can verify that it is legitimate by verifying the signature against the public key of the sender. As with protecting the confidentiality of messages, the digital signature relies on the essential property of the key pair; messages signed with the private key can only be verified using the matching public key and vice versa.
The signature that is created using the digital signing algorithm verifies the authenticity of that message. The digital signature guarantees that the sender of the message is who they say they are. Digital signatures have three important properties:
AUTHENTICATION—Digital signatures are regularly used to authenticate the true source of messages. When a private key is used to sign a message, a valid signature indicates that the message was sent by the holder of the private key, and this ensures sender authenticity.
INTEGRITY—In addition to being confident that the message came from who purported to send it, it is also important to ensure that the message has not been altered in any way during transmission. This is often referred to as “data integrity.” A digital signature can ensure that the message was received just as it was sent: if a message is digitally signed, any change in the message after it was signed would invalidate the signature.
NON-REPUDIATION—If a sender has signed some information, they cannot, at a later time, deny having signed it. Similarly, that someone has access to a public key of another does enable them to use that public key to forge a valid signature.
DNSSEC makes essential use of the first two of these properties of digital signatures. The fundamental feature that DNSSEC provides is to guarantee that the answer received as a result of a DNS query is exactly the answer that corresponds to the authoritative state of the DNS records related to that query.
DNSSEC Resource Records
DNSSEC is an extension to the DNS and it adds records to the DNS that can be used by DNS clients to validate the authenticity and integrity of an answer to a DNS query. Where a DNS server must indicate that it has no records with which to respond to a query, DNSSEC provides a way for this “negative answer” to be authenticated as well. To accomplish this DNSSEC adds a set of new DNS resource records:
DNSKEY
RRSIG
NSEC
DS
DNSKEY
Every zone file that is secured by DNSSEC has a public and private key pair. The administrator of the zone is responsible for keeping the private key secret. However, in order to check the signature on the zone data, DNS clients must be able to get a copy of the matching public key. As a result, the public key is published in the DNS using DNSSEC’s DNSKEY resource record. Here is an example of a DNSKEY record:
example.bank. 86400 IN DNSKEY 256 3 8 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
Cbl+BBZH4b/0PY1kxkmvHjcZc8no
kfzj31GajIQKY+5CptLr3buXA10h
WqTkF7H6RfoRqXQeogmMHfpftf6z
Mv1LyBUgia7za6ZEzOJBOztyvhjL
742iU/TpPSEDhm2SNKLijfUppn1U
aNvv4w== )
The Time-to-Live (TTL) value is one day (86,400 seconds). TTL is a value that controls how long any name server may cache the information that it may acquire in a query. The Flags value is 256, indicating that this is a Zone Key. The protocol value is a constant number: 3. The field that follows is the identifier for the public key algorithm, and the value 8 indicates RSA/SHA-256. The RR value is simply the encoding of the public key that the DNS client will use to validate the signed zone.
RRSIG
A Resource Record Set is a collection of resource records in a DNS Zone file that have a common name, class and type. In practice this means there would be a resource record set associated with each part of a DNS query response. Another way to say this is that the RRSIG is the Zone Administrator’s private key applied to the part of the zone requested by the client: a digital signature for the Resource Record Set.
In a typical zone with SOA (Start of Authority), NS (Name Server), A, MX (Mail Exchanger) and DNSKEY (Domain Name System KEY) resource records there would be five separate Resource Record Sets, each with a separate RRSIG record. Here is an example of a RRSIG record:
host.example.bank. 86400 IN RRSIG A 8 3 86400 20030322173103
(20030220173103 2642 example.bank.
oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrL
J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
The zone name is followed by the TTL value and the Class field. RRSIG indicates the resource record type. These three fields are followed by a “Type Covered” field which indicates that this is a signing of the A resource records in “host.example.bank.” The next field indicates the name of the algorithm used to sign the resource record set. The number “3” indicates that there are three labels in the original zone name (in this case, “host,” “example,” and “bank.”). The next field (86400) indicates the original TTL value for the covered A resource record set. Following that are date stamps indicating when the resource record set was signed and when the signature expires. The key tag is 2642 and the signer’s name is “example.bank.” The rest of the RR value is the digital signature of the resource record set.
NSEC
The DNSKEY and the RRSIG can be used to check the authenticity and the integrity of a DNS response, but only when there is a response. There needs to be a way to check the authenticity and integrity of a response when the DNS server is unable to find a result for the DNS query. The DNS doesn’t have a built-in resource record for this, so one was invented called the NSEC record.
The NSEC record was created so that something is returned in the event the resource requested does not exist. When a client makes a DNS query and either the name does not exist, or if the resource record type requested does not exist, the NSEC record is returned as a negative answer: a digitally signed indication that the name or resource record was not found.
Effectively the NSEC record is a way for the DNS server to bridge the gap between names in a secured zone. The strings in a zone file are sorted and then NSEC records are put in place to cover the gaps between the strings in the zone. If the zone contained the names “here” and “there” then there would be a NSEC record for “here” and its value would be “there” indicating that there are no defined names in the list of possible names between “here” and “there” Here is an example of a NSEC record:
alfa.example.bank. 86400 IN NSEC host.example.bank.
( A MX RRSIG NSEC TYPE1234 )
As before, the first four fields specify the name, TTL, Class and resource record type (this time, NSEC). This record then indicates that the next name, in sorted order, after “alfa.example.bank” in the zone is “host.example.bank.” The codes “A” “MX” “RRSIG” “NSEC” and “TYPE1234” indicate that there are “A” “MX” “RRSIG” “NSEC” and “TYPE1234” resource records associated with the name
alfa.example.bank. One implication of this is that, by collecting the information from the NSEC records, the entire contents of the DNS zone can be enumerated.
DS
To prove a zone file’s DNSKEY is truly authentic, the client first verifies that the parent’s copy is authentic. It does this by calculating the signature of the key inside the DS record using the parent’s public key. If it matches the RRSIG associated with the DS record, then the parent copy is authentic. Next, the parent copy is compared against the child’s copy—if they are the same, the parent has authenticated the child’s DNSKEY.
While there may be times when the parent zone’s public key is suspected of being compromised, the chain of trust means that the parent zone’s public key can be checked against the copy of the parent’s zone held by the parent of the parent. The same process can be used until the DNSSEC client encounters a “trusted” DNSKEY. The ideal “trusted” DNSKEY is that of the root zone—and the good news is that the root zone has been signed since June 2010.
Here is an example of a DS record for the zone example.bank:
dskey.example.bank. 86400 IN DS 60485 8 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )
As always, the first four fields are the name, TTL, Class, and resource record type (this time, the DS record). 60485 is the key tag for the corresponding “dnskey.example.bank” DNSKEY resource record. The number “8” indicates the algorithm used by “dnskey.example.bank” to construct the DNSKEY resource record. The value “1” indicates the algorithm used to construct the digest and the remainder of the record is the digest of the DNSKEY in hexadecimal format.
In essence, DNSSEC simply adds additional data to the responses that allow the DNS client to authenticate the resource records returned by the server.
If the client requests the security information:
If the string and resource record type being queried exist, the authoritative name server simply adds the RRSIG to the response;
If the string or the resource record being queried is not in the zone, the authoritative name server instead returns the NSEC record and its accompanying RRSIG record to indicate the negative response.
The DNS client can always take the returned RRSIG data and calculate its own copy of the signature to see if they match. The DNSKEY is needed to do this and if the client has not validated the DNSKEY within some set time period, the client needs to also validate the DNSKEY using the DS record stored at the parent zone. Each parent zone public key must also be validated in turn. Once the chain of trust is built and the signatures match, the DNS response can be considered to be validated and authentic.
DNSSEC and an fTLD Domain
To meet this requirement the zone, its parent zone, that zone’s parent zone, the fTLD Domain and the root of the DNS all must be signed. To tell if a zone is signed, all you need to do is see if it has a DNSKEY record. If it does, the good news is that it supports DNSSEC.
Fortunately, the root and fTLD Domain are already signed and have DNSKEY records. Suppose we want to sign example.bank—what would we need to do next?
Every zone gets two pairs of keys: the Zone Signing Key (ZSK) and the Key Signing Key (ZSK). It is common to generate those keys first. Then, the essential steps are:
Sign the zone with your ZSK
Sign the ZSK with your KSK
Publish the fingerprint of the KSK in the DS record published in the parent zone (for example, when signing the zone for example.bank, the DS record would be published in the .bank zone)
Every time the zone changes (perhaps a new domain is added to the example.bank zone, or the key needs to be updated) the zone must be resigned and the publishing task must be completed again. The process used for replacing one key in a zone with another is called a key rollover.
Keys in the DNS have a limited lifetime for security reasons. However, for fTLD Domain customers it is important that the existing chain of trust is not broken when the key rollover takes place.
A key rollover takes place when the records generated with the newest private key are first introduced into the zone. The key pair is often generated well in advance and the public key may also have been made public well in advance. Both key-signing keys and zone-signing keys are routinely (usually on a scheduled basis) rolled over.
DNSSEC Deployment for Registrars and Registrants
The process of generating keys, signing zones, generating, uploading and publishing DS records and managing key rollover is complex.
Registrars must support DNSSEC and provide tools for registrants to help publish DS records. Registrants must also support DNSSEC and have the tools for generating keys, signing zones, generating, uploading and publishing DS records and managing key rollover.
In cases where the registrant outsources the management of their fTLD Domain zone, they must ensure that the third party is able to successfully generate keys, sign their zones, generate and upload the DS records and manage key rollovers. For organizations that choose to outsource the DNSSEC management activity, there are a variety of vendors with service offerings that will comply with the fTLD Domain DNSSEC requirement. Web hosting companies, registrars and DNS management services may have service offerings that can assist a registrant in complying with the DNSSEC requirement.
In cases where a registrant has decided to implement DNSSEC on their own servers, it is useful to have tools that will help key management, signing, publishing and rollover tasks. In addition to commercial
tools that are easily found using simple searches on the internet, there are two primary open source approaches available:
OpenDNSSEC project at http://www.opendnssec.org
DNSSEC-Tools project at http://www.dnssec-tools.org
TLS stands for Transport Layer Security. TLS is an open standard for encryption that makes it possible for people and applications to communicate in private over the internet. When a client and server communicate, TLS is used to ensure the messages passed between them cannot be read or changed during the transmission. TLS is the successor to a technology called Secure Sockets Layer (SSL) and it provides three essential services to help ensure security on the internet:
TLS is often associated with protecting the contents of messages, but the protocol is also very useful in protecting against threats such as masquerade attacks, man-in-the-middle or bucket brigade attacks, rollback attacks and replay attacks.
What are the fTLD Domain Security Requirements for TLS?
There are three requirements that reference TLS/Encryption:
These TLS/Encryption requirements:
An fTLD Domain is an HTTPS-only community to support confidentiality and integrity of web and other services by default. As .BANK and .INSURANCE are on the HSTS preload list (HSTS information here and here), domains that are not HTTPS compliant will not be accessible via most major browsers (e.g., Chrome) following this list. As a global HSTS security policy becomes increasingly common, additional browser are expected to block sites that are not HTTPS compliant. For more information on browser hygiene and security, please visit: https://www.ftld.com/secure-your-browser/
Public key certificates (also known as a digital identity or TLS certificate) must be deployed to secure fTLD Domains and subdomains to meet the TLS/Encryption requirement. Registrants may wish to use a wildcard certificate (e.g., *domainname.BANK; *domainname.INSURANCE) which allows a public key certificate to be used across single-level subdomains. Public key certificates must not be generated using any prohibited cipher suite components.
TLS applies to all domains and subdomains and must be implemented using version 1.2 or greater where possible as follows:
Server-to-Server Email: For domains sending or receiving email, TLS v1.2 or greater must be offered. Earlier versions of TLS/SSL are permitted, including, defaulting to unencrypted email when it is not possible to provide encryption.
Prohibited Cipher Suite Components
The following is a non-exhaustive list of cipher suite components (authentication, encryption, message authentication code and key exchange algorithms) excluded from use with in-zone domains and in the generation of TLS certificates: Anon, DES, 3DES, FIPS, GOST 28147-89, IDEA, SEED, WITH_SEED, MD5, NULL, SHA (SHA1), RC4, EXPORT, EXPORT1024 and SRP.
How Does TLS Work?
TLS is built from a pair of protocols: the “record” protocol and the “handshake” protocol. Fundamentally, TLS exchanges records—the content and formatting of those records being agreed at the start through a “negotiation” between client and server. The content of those records may be control messages for TLS, the actual encrypted content flowing between both parties and a variety of other information. The TLS Record Protocol provides connection security that has two basic properties:
The shared secret is important because symmetric cryptography is significantly faster than public key cryptography. However, the shared secret is a problem because both endpoints need to know the same shared secret to exchange messages; this is where the TLS Handshake Protocol plays a role. The TLS Handshake Protocol provides connection security between two endpoints on the internet, and has the following three properties:
The combination of the negotiated secret provided by the TLS Handshake Protocol and the symmetric cryptography and checksums provide a secure communications channel for any application layer protocol on the internet (e.g., World Wide Web, email, VoIP). The handshake is essential to TLS, but also fairly complex. The following overview describes the handshake when both ends of the connection must authenticate themselves to one another.
TLS is a powerful tool for ensuring secure channels of communications. However, there are known attacks on the protocol and every security professional working with an fTLD Domain should be aware of the known vulnerabilities of TLS. Details are beyond the scope of this document, but a summary is available here: https://tools.ietf.org/html/rfc7457.
Crucial to the handshake is the availability of a digital certificate. Digital certificates are files with a specific, standardized format which attests to the identity of an entity. That entity could be nearly anything such as a person, a named user, a server, a smartphone or a program on a client. Inside the certificate, along with the attestation of identity, is the public key. Here’s what a sample certificate looks like:
When using TLS, each side of the connection can use the digital certificate to try to validate its contents and the claim of identity for the entity. One of the fields that is often used for this is called the “Common Name.” Each side of the conversation can check the Common Name against what they expect. They can also check the expiration date of the certificate. Especially useful in these circumstances, both sides can check who issued the certificate. Digital certificates are issued by Certificate Authorities (CA). There are companies that offer a service to do validation of the identity information in the digital certificate and then issue certificates that they can confirm. These companies are often called Trusted Certificate Authorities. The real value of certificates appears when they come from a trusted source.
TLS/Encryption for an fTLD Domain
The primary use for TLS in an fTLD Domain environment is in securing activity on the internet. The first requirement specifies that registrar and registrant access to registration systems must be mutually authenticated via TLS and secured with multi-factor authentication, NIST Level 3 or better.
When the registration system is an application running in cooperation with a web server, this implies that the clients and servers must have digital certificates, must support at least the TLS specified in the Requirements, and must be able to fully negotiate the handshake that sets up the secured session.
The second requirement specifies that all electronic communication between parties, including, but not limited to, web access, mail exchange, and file transfer, use encrypted protocols to prevent tampering with messages.
The third requirement specifies that TLS must be implemented using trusted protocol versions because some early implementations of TLS and some cipher suites supported by the protocol are known to be insecure. A public key certificate must be used to meet this requirement.
fTLD Domains must support the TLS specified in the Requirements. Changes to TLS protocols are ongoing and registrants should confirm the current requirement. Registrants and registrars will be notified of changes to any Requirements on a timely basis.
In addition, a series of cipher suites which are currently known to be insecure are not permitted for use with an fTLD Domain and are identified in the third requirement. Detailed information on the TLS/Encryption requirements is available in the Implementation Guidelines here: https://www.ftld.com/security.
The steps required to implement TLS on a web server is discussed in the next section of this document. If the services are built to be used via a web browser, access through the https:// schema makes TLS implementation straightforward. Services built to be used through other tools, for instance through an iPhone, Android or Windows Phone app, need to use the secure transport APIs for the particular platform being targeted.
All component parts of web pages on websites from an fTLD Domain must be sent using TLS. It is possible to build “mixed-content” web pages, which are sent from server to client over TLS, but include resources (e.g., images, CSS or JavaScript files) that are not protected by TLS. However, such pages are not secure and are prohibited because of the third requirement. An active man-in-the-middle (MITM) attacker can piggyback on a single unprotected CSS file, as an example, and hijack the entire user session.
However, this does not prohibit an fTLD Domain from using content from other services. As an example, if an fTLD Domain incorporates information from a social media feed, the content from the social media may not originate or be hosted from an fTLD Domain service. It is acceptable to incorporate content from other sources in an fTLD Domain.
In addition to implementing TLS, registrars and registrants may choose to implement HTTP Strict Transport Security (HSTS). HSTS is effectively a backup for TLS. It was engineered to ensure that security remains intact even in the case of configuration problems and implementation errors. HSTS protection is simple to implement: you set a single response header in your websites. After that, browsers that support HSTS will enforce it. While the use of HSTS is not currently a requirement, it is strongly encouraged by fTLD and may become a requirement in the future.
Once implemented, HSTS does not allow any insecure communication with the website that uses it. It achieves this goal by automatically converting all plaintext links to encrypted ones. It also makes it harder for a user to click-through certificate errors and warnings which may be a leading indicator of a more significant problem such as malware or a man-in-the-middle attack (Certificate errors are a potential indicator of an active MITM attack. Studies have shown that almost all users click through these warnings without heeding them.).
TLS/Encryption Deployment for Registrars and Registrants
For an fTLD Domain, implementing TLS on web servers requires six primary steps:
In step 2, above, the Certificate Authority generates the Certificate used for TLS. The certificate is tied to a specific FQDN. fTLD suggests that registrars and registrants ensure that their certificates cover all the names to be used with a site. If the main domain name is going to be www.myexample.bank, you may also wish to have certificates configured for myexample.bank and other names which users might use (or, which your financial institution uses for brand recognition purposes); a wildcard certificate (e.g., *.myexample.bank). is one solution to cover every DNS name. A secure fTLD Domain web server should have a certificate that is valid for every DNS name configured to point to it. The goal is to avoid invalid certificate warnings at the browser, which will potentially confuse users and may weaken their trust. Once installed and configured, the server should be able to respond properly to client requests for TLS sessions. It is possible to test the configuration of the server and determine if the combination of the certificate installation and the server configuration has been successful. Several organizations provide free services to make this check such as:
Encryption of Web, Mail and Other Service Ports
As an example, in the case of electronic mail, one approach for meeting this requirement (typically for legacy systems) is to implement implicit encryption via STARTTLS. STARTTLS is a protocol level command that improves upon plaintext protocols such as email and file transfer. Essentially, STARTTLS provides a way to upgrade plaintext communications to an encrypted, TLS-based connection. The advantage of STARTTLS is that legacy services like email (in RFC 2595 and RFC 3207), instant messaging (in RFC 6120), and directory services (in RFC 2830) are supported.
An alternative, and typically preferred solution to STARTTLS is leveraging explicit encryption solutions. Internet standards bodies have designated certain ports to secure (TLS-based) services. This is an analog to HTTP and HTTPS. For instance,
Today most mainstream providers of services—especially email and file transfer—employ clear text (unencrypted) communication only as a legacy approach. For instance, Google has a real-time report on email encryption available at: google.com/transparencyreport/saferemail/
Commercial software supporting these internet services widely support both implicit and explicit TLS implementations. As an example, Microsoft Exchange uses a feature called Opportunistic TLS that enables TLS by default for the server. This enables any sending system to encrypt the inbound SMTP session to Exchange. By default, Exchange 2013 also attempts TLS for all remote connections.
Traffic should be encrypted as the default option. Services in an fTLD Domain should always attempt to have transmission encrypted. The only case where defaulting back to plaintext for transmission is in extraordinary cases: for instance, sending emails to legacy domains. In those cases STARTTLS should always be attempted before falling back to clear text. It should be noted email is not analogous to web traffic. All modern browsers support strong encryption; web servers should never downgrade to an unencrypted HTTP connection.
EMAIL AUTHENTICATION
Much of the communication on the internet still depends on one of the oldest internet services: electronic mail. Social networking and other mobile services have not changed this. More than ever, those wishing to do harm on the internet have a tremendous financial incentive to compromise user accounts, enabling theft of passwords, bank accounts, credit cards and other security violations. The original electronic mail protocols never envisioned the risks to consumers in simple email spoofing. In some cases, the simple insertion of a logo of a famous brand is enough to give email legitimacy with many users.
Even sophisticated users can be fooled by fake messages. And large providers of mail services have to make very difficult choices about which messages to deliver and which ones they should not. DMARC is a technical specification, using the DNS and mail servers, to attempt to deal with some of these issues. The goal is to help email senders and receivers work to reduce the number of phishing attacks and other malicious email-borne activities.
There are three standards that make up the email authentication technology:
fTLD recommends that both SPF and DKIM be used with DMARC. However, the requirement only specifies that an SPF record must be created. In practice, email authentication is more effective in the presence of both SPF and DKIM records as email delivery rates will be increased.
What is the fTLD Domain Security Requirement for Email Authentication?
Registrants that have met requirements #1 and #2, and therefore appear in the .BANK or .INSURANCE zone, must publish a valid Domain-based Message Authentication, Reporting and Conformance (DMARC) record whether or no the domain is used to send email.
For a domain used to send email: Registrants must publish a DMARC record with a "reject" mail receiver policy (p=reject), except during the implementation phase of email set up as described below*. In addition, Registrants must publish a Sender Policy Framework (SPF) record. While publishing a DomainKeys Identified Mail (DKIM) record is not required, publishing both SPF and DKIM records creates additional security for your email channel.
It is recommended that DMARC records specify strict identifier alignment for both SPF and DKIM (if applicable) via the adkim and aspf tags. Also, for DMARC records published at an organizational domain level to set an appropriate "sp: tag" for subdomains.
When used to protect non-email sending domains, Registrants are required to publish a DMARC reject (p=reject) mail receiver policy.
Benefit: The goal of this requirement is to provide an increased level of trust for email from an fTLD Domain. This is done by using an internet-standard approach to email authentication. This is a crucial requirement for ensuring that the electronic mail channel for an fTLD Domain is protected against the delivery of invalid or spoofed email purporting to be from an fTLD Domain.
Implementation of email: When deploying DMARC during the implementation phase of email capabilities, Registrants may temporarily use a “none” (p=none) or “quarantine” (p=quarantine) mail receiver policy, but must change the policy to reject for ongoing operations within 90 days of deployment.
What is Email Authentication and Why is it Important?
Email authentication allows the receiver of an email to make judgments about the sender of the email. In addition, the sender can develop and publish a policy for email authentication. If a receiver can establish authentication of the source of email, then one of the most difficult problems for email can be avoided— spoofing also known as phishing. Spoofing is the ability of someone to pretend to be another organization and attempt to lure an email receiver into using a rogue website instead of an authentic website or into providing confidential information in order to compromise sensitive user information.
For organizations using an fTLD Domain, email authentication is an essential part of establishing trust in email coming from their organization. Email authentication assists in the prevention of phishing attacks and also plays a role in emerging reputation and accreditation systems that are another part of establishing trust in email as a vehicle for communications between financial services organizations and their customers. There are two basic types of email authentication: internet Protocol-based approaches and cryptographic approaches. The internet Protocol approach, SPF, requires publishing information about legitimate email servers in the DNS for each domain being used. The other approach, cryptographic, attaches a signature to each message in a way that is difficult to forge, proving that the message came from the indicated sending domain. The industry standard for cryptographic authentication is DKIM. Today, companies are moving toward adoption of SPF, DKIM, or both. Major email providers such as Microsoft, Yahoo! and Gmail are using both SPF and DKIM to authenticate email senders. DMARC is a tool that uses SPF or DKIM to make decisions about incoming mail based on a published policy.
Understanding Email Authentication Protocols
The email authentication protocols are complex. While this section provides a basic overview and some examples, there are resources available to learn more about SPF, DKIM and DMARC. This section provides links to some of the available sources of information on the three protocols.
Example: Building a SPF Policy
In this section, fTLD provides an example for illustration purposes of what is needed to build an SPF policy record to meet the requirement. Registrants in an fTLD Domain zone are required to have an SPF or DKIM record. Similar to the DNSSEC resource records noted earlier in this guide, an SPF record is a resource record that identifies which mail servers are permitted to send email on behalf of your domain.
The idea behind an SPF record is to prevent spammers from sending messages with forged “From” addresses at your domain. This is especially important in the case of an fTLD Domain where the goal is to establish high levels of trust between institutions and their customers. Email service providers (e.g., Google, Microsoft, Yahoo!), on behalf of their customers, refer to the SPF record to determine whether a message purporting to be from your domain comes from an authorized mail server and then deliver it or not.
For example, suppose that your domain example.bank uses your internal mail server. You create an SPF record that identifies your internal mail server (suppose it is mail.example.bank) as the authorized mail servers for your domain. When a recipient’s mail server receives a message from customerservice@ example.bank, it can check the SPF record for example.bank to determine whether it is a valid message. If the message comes from a server other than your internal mail servers listed in the SPF record, the recipient’s mail server can reject it as spam. It’s perfectly possible to have an SPF record that authorizes more than one domain as the legitimate server for your outbound email.
If your domain does not have an SPF record, some recipient domains may reject messages from your users because they cannot validate that the messages come from an authorized mail server.
The diagram below shows how SPF is used to provide the “Envelope From” information as part of the DMARC standard.
Suppose a mail is sent with the following address information:
Mail-from: customerservice@example.bank
From: customerservice@example.bank
To: steve@zelda.example.org
In SMTP, when one mail server connects to another the sending server introduces itself. In our example, let’s say the sending server says HELO mail.boston.example.bank. Now that we know the hostname the sending server claims to be, we can check that. We do that by looking up the SPF record for mail.boston.example.bank, which might look like this:
mail.boston.example.bank.
TXT “v=spf1 a -all”
This record tells us that the only host that can announce itself as mail.boston.example.bank is mail.boston.example.bank (indicated by the “a”). Note if there was no SPF record for mail.boston.example.bank, the result would be None, rather than Pass or Fail.
If the IP address of the sending server matches the IP address of mail.boston.example.bank, we have a Pass result for SPF.
If the IP address of the sending server does not match the IP address of mail.boston.example.bank, we proceed to the next part of the SPF record, -all, which yields a Fail result.
Since the mail-from shows an @example.bank address we look up the following SPF record:
example.bank. TXT “v=spf1 a:mail.boston.example.bank -all”
This record indicates that there is only one server that is allowed to send mail using the example.bank domain, and that is mail.boston.example.bank. Now that we know that, we look up the IP address of the mail.boston.example.bank host.
If the IP address we find for mail.boston.example.bank matches the IP address of the incoming connection, then we have a match and the SPF test yields a Pass result.
If the address does not match mail.boston.example.bank, then we go on to the next part of the SPF record, in this case “-all” which tells us that any other IP address yields a Fail result.
SPF Practical Limitation
A single SPF record can contain a maximum of 10 DNS lookups to see if you authorize a particular IP address to send mail on your behalf. This practical limitation should be observed to ensure timely delivery of email messages and favorable inbox ratings. There are several ways to avoid this limitation such as:
See: https://dmarcian.com/spf-syntax-table/#toomany.
Example: A DKIM Record
The requirement identifies that registrants may use DomainKeys Identified Mail (DKIM) as one of the two options for authenticating email messages in compliance with DMARC. DKIM is an email validation system that allows a mail server to check that a domain is authorized to send a particular piece of email and verify that the message has not been modified during its transport through the network. DKIM works differently from SPF in that DKIM uses a digital signature to sign the message. This signature is added to the content of the message and the recipient can then use it, along with a public key published in the DNS, to verify that the message was sent by an authorized person and that the message has not been altered.
DKIM consists of a signing and verifying application usually built into a mail server.
DKIM requires that there be a public key available for the validation process. It works like this:
myselector._domainkey.example.bank TXT “k=rsa; p=AIGf ... AQAB”
Notice that there is a selector attached to the special domainkey subdomain. Here is a list of the possible options for this text record and their meanings:
With these two special TXT records in the DNS we can now see how DKIM works in practice. The sending server inserts a mail header in the message called the “DomainKey Signature.” Effectively, this is a digital signature over the entire message contents using the private key of the server. A sample might look like this:
DKIM-Signature: a=rsa-sha1; s=myselector; d=example.bank; i=customerservice@mail.example.bank; c=simple; q=dns; b=dydVyOfAKCdLXdJOc8G2q8LoXSlEniSbav+yuU4zGffruD00lszZVoG4ZHRNiYzR;
When this recipient gets the message, the server can look up the public key for example.bank and then calculate whether or not the message contents are the same as what was sent. It also allows the recipient to find out the signing organization’s message signing policy.
We’ve seen how SPF and DKIM can add message authenticity to the sending process. The following diagram shows how DMARC fits into the process.
Example: DMARC in Practice
A DMARC policy uses the DNS to allow a sender to indicate that their emails are protected by SPF and/or DKIM. DMARC also suggests what the recipient should do if neither of those authentication methods passes—for instance, delete, none, quarantine or reject the message.
For an fTLD Domain, DMARC removes guesswork from the receiver’s handling of these failed messages. It also provides a user the ability to eliminate fraudulent or harmful messages falsely purporting to come from an fTLD Domain. DMARC also provides an optional mechanism for receivers to report back to the sender about messages they receive with DMARC evaluations.
Here’s an example DMARC record:
_dmarc.example.bank. IN TXT “v=DMARC1; p=reject; rua=mailto:postmaster@example.bank; ruf=mailto:dmarc@example.bank”
Here is a list of the possible options for this text record and their meanings:
*If you use a non-.BANK | .INSURANCE email address for the rua | ruf tags, you may not receive the DMARC reports associated with your domain unless you have configured an external reporting authorization record in the target domain name.
The alignment modes for SPF enables an administrator to manage which parts of the message are authenticated by either SPF. Alignment, for DMARC DKIM, has to do with whether the signing domain used for the signature must strictly match the RFC5322 “From” domain, or if the signing domain and RFC5322 domains must merely be domains within the same organization domain, e.g., proper subdomains of the org domain, or one the organizational domain and the other a subdomain. Since the alignment can be different in diverse implementations, DMARC allows both “strict” and “relaxed” versions of the alignment with the goal of checking against the MailFrom portion of the incoming message.
The requirement suggests, but does not require, that the identifier alignment for both SPF and DKIM be set to “strict.” Also, the optional pct tag is helpful during implementation. It can be used to stage and sample your DMARC deployment. Since 100 percent is the default, passing “pct=20” in your DMARC TXT record results in one-fifth of all messages affected by the policy actually receiving the disposition instead of all of them.
Tip: Ensure that your organization’s incoming mail service provider/server is properly configured for DMARC and this is on top of having properly formed DMARC and SPF records. For common mail service providers like Gmail, Microsoft 365 (for inbound email only), and Yahoo!, they do this for you. If you use Microsoft 365 with a custom domain or an on-premise Exchange server, you’ll need to manually implement DMARC for your outbound mail (learn more about this here).
DMARC Deployment for Registrars and Registrants
Parts ofDMARC deployment and mail authentication can be challenging, but there is a large body of information available for implementers and fTLD can help you navigate hurdles and check that your implementation meets our requirements.
For those organizations running their own mail and DNS servers, there are both commercial and open source tools to add to existing mail servers. For organizations who want to offload the mail services to a separate appliance several message gateways have built-in DMARC support. Several tools have been released that support enterprise-class DMARC support in large scale email tools (e.g., Hexamail Guard for Microsoft Exchange).
For organizations that outsource their email services, there are a variety of third-party providers of hosted email that support SPF, DKIM and DMARC. In addition, it is possible to have a third-party sender relay your mail through a server you provide. Similar to DNSSEC, it is necessary to work with the organization that is hosting your email in order to ensure that when they send email on your behalf it is DMARC compliant.
NAME SERVER RESTRICTIONS
A DNS name server translates human-memorable domain names and host names into corresponding Internet Protocol (IP) addresses to locate computer systems and resources on the internet. DNS allows for two types of name servers:
When a secondary master starts, it contacts its master name server and pulls the zone data over—this is called a zone transfer. Once the zone transfer is completed, both the primary master and the slave name servers are authoritative for that zone. There are good operational reasons for using additional DNS servers for zone replication:
Added DNS servers provide zone redundancy, which makes it possible for DNS names in the zone to be resolved for clients if a primary server for the zone stops responding.
Added DNS servers can be placed to reduce DNS network traffic. For example, adding a DNS server to the opposing side of a low-speed, wide area network (WAN) link can be useful in managing and reducing network traffic.
Additional secondary servers can be used to reduce loads on a primary server for a zone.
What is the fTLD Domain Security Requirement for Name Server Host Names?
Name server host names must be in the parent zone. This requirement ensures that authoritative name servers are trusted and reliable.
Host Name Deployment for Registrars and Registrants
A Name Server (NS) resource record indicates that a name server is authoritative for a zone. For instance, consider the records below:
These records would state that there are three name servers for example.bank. To help ensure that these three name servers are trusted, the NS records are published in the parent zone.
For those organizations configuring and running their own DNS, control over the zone files is simple to arrange. For organizations that outsource DNS and zone management, they will need to work with their third-party provider to ensure that this requirement is met. Operationally, even in situations where a third party is assisting with the configuration and management of the DNS, complying with this requirement is very straightforward.
301/URL REDIRECTION
A 301 redirect, also known as URL redirection, is used to automatically forward site visitors from one URL location to another (e.g., www.BankName.com to www.BankName.BANK). A 301 redirect, is key to maintaining a website's domain authority and search engine rankings when the site's URL is changed. It easily sends visitors to a different URL than the one they originally requested -- without having to know or type in a different URL.
Why use a 301 redirect?
With a 301 redirect in place customers attempting to visit your .com site, via bookmarks/favorites, links in emails, or by typing your .com domain into their browser, will automatically be redirected to your .BANK site, ensuring all customers can easily get to your new .BANK domain. Even better, a 301 redirect enables you to maintain your search engine rankings from your current .com site on your new .BANK site. Since visitors will be automatically redirected to your new .BANK domain you can educate customers about your move to .BANK on your new .BANK site, as opposed to doing extensive and expensive education ahead of time. Redirection also means you can continue to use current business cards and letterhead until you begin to run low, because your .com address will continue to work, saving you the expense of immediately reprinting all bank collateral.
There are various reasons to use URL Redirection and here are some common examples:
Regardless of the reason for using URL Redirection, when .BANK and .INSURANCE are used to serve content on the Internet they must be secured with a Transport Layer Security (TLS) certificate that meets fTLD’s Digital Identity Certificate and TLS version requirements.
What method of URL Redirection is more secure?
HTTP(S) Redirect, a “redirect” feature of the HTTP protocol, is more secure than other methods and has the added advantage of being easier to maintain in the long term. This is why it is the recommended and standard method for URL redirection, and you should use it by default. Other non-standard forms of URL Redirection, such as Meta Refresh and Javascript, are less secure, more challenging to maintain, do not support various types of redirection (e.g., temporary vs. permanent), can lead to a bad user experience (e.g., concerns about security if the redirect is not expected, the “Back” button causing some browsers to move back to the redirecting page) and in the case of Javascript redirects, some browsers may not support it.
How to setup a 301/HTTPS redirect:
https://support.google.com/webmasters/answer/93633?hl=en
https://www.pair.com/support/kb/how-to-set-up-a-301-redirect/
https://moz.com/learn/seo/redirection
https://www.123-reg.co.uk/support/hosting/301-redirect/
HSTS in .BANK and .INSURANCE
fTLD has implemented HTTP Strict Transport Security (HSTS) at the Top-Level for .BANK and .INSURANCE to declare that web browsers should only interact with .BANK and .INSURANCE websites using secure HTTPS connections, and never via the insecure HTTP protocol. As a result, browsers such as Google Chrome and Microsoft Edge will automatically take a visitor to the secure version of the domain provided it’s secured with a TLS certificate. In contrast, HSTS prevents non-compliant, insecure HTTP sites from loading at all. This means you will need to ensure you have a TLS certificate for your .BANK/.INSURANCE domain(s), including for URL Redirection which must be made securely.
The following blog includes information on how to set-up secure (i.e., HTTPS) URL Redirection:
https://blog.dnsimple.com/2016/08/https-redirects/
Check your URL Redirection
A couple of public tools fTLD finds to be instructive are Redirect Detective: https://redirectdetective.com/ and Redirect Checker: https://www.redirect-checker.org/index.php. By entering a URL on Redirect Detective you can see the path of the redirection(s), and if none are set up, it will say so.
The following are examples of URL Redirection with the Security Requirements compliance or non-compliance indicated:
EMERGENCY SITUATIONS
What is the fTLD Domain Security Requirement for Emergency Situations?
In Emergency Situations (i.e., "Incident") Registrants are exempt from the following Security Requirements: DNSSEC, TLS/Encryption, Email Authentication and URL Redirection. Registrants are required to provide written notification to fTLD of Emergency Situations lasting longer than three (3) business days by the end of the third business day.
The Requirements are an important basis for enhancing the default security posture of registrants and to create a safer ecosystem to maintain trust and facilitate commerce. However, fTLD recognizes that despite best efforts, cyber attackers can from time-to-time bypass or render security controls ineffective, potentially causing significant harm to registrants and their customers.
These Emergency Situations are defined as present or imminent events such as:
In the course of responding to an Emergency Situation, registrants may decide their existing security posture is untenable and require a new approach to defeat or lessen the impact of a particular threat. Registrants are encouraged to take any action they deem appropriate to protect themselves, their infrastructure and their customers and the Requirements shall not be interpreted in a way to impede self-defense.
However, should defensive actions conflict or contravene the technical requirements, registrants must apply for, and, in the meantime, may operate under the presumption of being granted, a temporary exemption to one or all of the technical requirements.
Whether or not an exemption to the Requirements is necessary and appropriate, any Emergency Situation lasting longer than three business days requires written notification of the incident by the registrant to fTLD by the end of the third business day.
Requirement exemptions and/or notice of incidents lasting longer than three business days must be submitted through the Emergency Situation Notification Form found here: ftld.com/incident-form/.
OTHER CONSIDERATIONS
Working with Vendors
Third-party providers have emerged whose business is built around helping .BANK or .INSURANCE Registrants meet the Security Requirements. fTLD has identified several third-party providers that can assist you in complying with the Requirements; see them here: .BANK and .INSURANCE.
Using a third-party provider does not obviate or transfer your responsibility for compliance with the Security Requirements. Any arrangement with a third-party provider supporting or hosting an fTLD Domain must be compliant with the relevant Requirements, and this may mean that the registrant needs to contractually bind its third-party providers to implement them. For example, if you use a vendor to manage marketing mail-outs to your customers then you likely need to modify your DMARC, DKIM and SPF records to include your authorized third-party email senders. It is your responsibility to ensure your third-party providers comply with the Requirements. Ongoing expenditures will be necessary to maintain, monitor and demonstrate compliance with the Requirements. To illustrate, in a DNSSEC deployment, if you add a new name or level to your second-level domain. For example, if you create a new product or service and a new name to go along with it— www.newservice.yourbank.bank—you will need to re-sign the zone and re-publish it. If you change mail servers, or use third-party email senders, you will need to immediately update the DMARC record to reflect this. You may wish to investigate specialized DNS or email authentication providers that can meet the Requirements, and find new partners to facilitate your implementation.
KEEPING UP TO DATE WITH THE SECURITY REQUIREMENTS
fTLD will periodically review and update the Requirements to continue to evolve and stay ahead of the threats they are designed to mitigate. As these updates occur, you will be provided reasonable notice to implement them.
Our promise to you is that fTLD will continue work collaboratively with industry and security experts to ensure that the Requirements represent best practices and security measures to ensure the security of .BANK and .INSURANCE domains and your customers’ well-placed trust.