November 27, 2017
Originally, there were just seven generic top level domains (gTLDs) and a couple hundred country code TLDs (ccTLDs). In 2012, ICANN announced the application for nearly 2000 new gTLDs. Within these applications were requests for about 500 Brand TLDs.
The 2012 gTLD application program, allowed applicants to request their brand to be a gTLD. If the request was accepted, the applicant would have to accept Specification 13 to their registry contract. This specification states applicants must meet the following requirements:
- The TLD string is identical to the textual elements protectable under applicable law, of a registered trademark valid under applicable law;
- Only Registry Operator, its Affiliates or Trademark Licensees are registrants of domain names in the TLD and control the DNS records associated with domain names at any level in the TLD;
- The TLD is not a Generic String TLD (as defined in Specification 11); and
- Registry Operator has provided ICANN with an accurate and complete copy of such trademark registration.
Secure the Brand TLD
A Brand TLD allows companies such as Ford to have domains ending with .ford, Netflix to have .netflix and Google to have .youtube. A Brand TLD allows the company to communicate its brand through the URL. It also enables the company to control policy and security for the whole TLD.
Think of the opportunities that result from protecting your Brand TLD:
- All communications are secure
- User’s privacy is protected
- Domains are protected
- Certificates come from your trusted certification authority (CA)
- Mitigation of phishing and man-in-the-middle (MitM) attacks on your sites
First, why not HTTPS secure every site under the Brand TLD. This again will secure all communications between your site and your customers or end users. It will also provide privacy to the same end users.
Your end users can be alerted to unsecure HTTP sites by using HTTP Strict Transport Security (HSTS). This is a server header which advises the browser your site must be protected with HTTPS.
Perhaps the whole Brand TLD could be added to the HSTS preload list. Chrome, Firefox, Opera, Safari, IE 11 and Edge support HSTS preload. You can add your Brand TLD to the HSTS preload list by reaching out to https://hstspreload.org/#contact, proving you control the TLD and understanding all sites must be HTTPS protected. Google already supports this process and will require HSTS for 45 of their Brand TLDs.
Extended Validation (EV) Certificates
EV certificates have a unique property as they have a certificate policy OID, which is in common with the same OID that is assigned to their root certificate. As such, an EV certificate is only trusted if it is associated with an EV root.
Fraudulent certificates are typically domain validated (DV) certificates. It is easier to obtain a DV certificate as you only need to prove control of the domain name. This can fraudulently be accomplished by attacking DNS or the WHOIS of a registry or obtaining a trusted email address. The result will allow an attacker to obtain a certificate to support a phishing or MitM attack.
If your branded domain uses EV, then many of your users will expect to see the EV indication. A fraudulent certificate will remove the EV indication.
Certificate transparency (CT) is a log of many SSL/TLS certificates. Starting in April 2018, Google has requested all new certificates to be CT logged to have trust with Chrome. Apple, Mozilla and Microsoft also plan to support CT in their browsers. Monitoring CT logs may indicate if any unauthorized certificates were issued with your Brand TLD. If a miss-issuance occurs, a request can be made to the CA to revoke the certificate.
Certification Authority Authorization
Certification authority authorization (CAA) allows the domain owner to permit one or many CAs to issue certificates with your domain name. Starting in September 2017, all CAs must check CAA records. If there is no record, then any CA may issue for your domain. If there is a CAA record, then only the permitted CA(s) may issue. Brand TLD owners should use CAA to limit the CAs that can issue certificates for their brand.
Wildcard certificates will protect subdomains of a base domain. In other words wildcard *.example.com will protect www.example.com and buy.example.com. The issue is that the certificate will indicate trust to approved and unapproved domain names (e.g., facebook.example.com). Issuance or non-issuance of wildcard certificates should be considered as part of your certificate policy. A Brand TLD owner has the opportunity to stop wildcard certificate issuance through a CAA record.
Branded Certification Authority
If you have a Brand TLD, then why not a branded CA certificate. With such a certificate, the brand owner can have all of their certificates issued from a CA with the same brand. This CA can also be used as the only one authorized for CAA. With such a deployment, your site and your certificates will promote your brand and also extend security to your users and your data.
Good News for Non-Brand TLDs
Even if you do not have a Brand TLD, you can use the same recommendations to protect your web site. HSTS, EV certificates, CT monitoring and CAA are all great methods to protect your site and your users information.
This is a Security Bloggers Network syndicated blog post authored by Entrust Datacard Blog. Read the original post at: Entrust Datacard Blog