ICANN70: At the crossroads of different policy development processes

Initially scheduled to take place in Cancun, Mexico, like ICANN67 , the recent summit on Internet governance was once again held entirely by videoconference due to the global health situation. The PDPs, the Policy Development Processes, were the main thread of this summit.

ICANN 70
ICANN70 was the fourth summit held remotedely

The PDP, Policy Development Process, is the central community mechanism used by the Generic Names Supporting Organization (Gnso), the body responsible for policy developments on generic domain names, to propose new requirements and revise existing rules to update them. Each PDP results in a series of reports that are ultimately forwarded to the ICANN Board of Directors, which decides on the fate of the recommendations they contain. 

News on the PDP of the new generic extensions

It is with this mechanism that ICANN launched a program of new generic extensions that led to 1930 applications in Spring 2012 and 1233 delegated extensions by the end of 2020. The opportunity to consider a new round of applications was materialized by a PDP initiated by Gnso in late 2015. Five years later, this process to review and improve the Gnso recommendations for the 2012 cycle has entered its final stretch. It is now up to the ICANN Board to decide on the recommendations of the working groups that worked on this PDP. The Board of Directors should launch a last phase of consultations of the community before pronouncing on the continuation of their works. The community was expecting an announcement at this summit or perhaps even a timetable to mark out the next steps until the next round of applications, but we have to admit that hopes have been dashed. Indeed, no announcements were made, even though we know that the prospect of a future round of applications is now approaching fast. Regarding the content of the recommendations this time, the elements discussed mainly during ICANN70 were about a pre-evaluation of the future registries, the improvement of the predictability to evaluate the future applications and the ways to improve the applicants’ support.

The PDP: A solution to the impasse over malicious use of the DNS?

Another topic, related to the implementation of the PDP mentioned above, is the malicious uses of the DNS, a topic commonly referred to as DNS abuse.

ICANN’s monitoring of malicious practices in generic names covers some 205 million domain names, of which barely 11% are from the cycle of extensions created since 2012. The observation made through their analyses shows that around one million domains concentrate these infringements, that is to say 0.5% of them. Another notable fact is that the new generic extensions are more used for malicious practices than the historical generic extensions like .COM, .NET, .ORG, .BIZ and .INFO. In fact, ICANN indicated that in February 2021, 35% of security breaches came from names created in the new generic extensions against 65% in the historical extensions, a ratio that even rose to 40% in November 2020. ICANN also said that 90% of malicious practices in the new extensions were concentrated in 23 extensions. As for the most common types of attacks, spamming is involved at 85%, phishing at 8.4%, botnets (malicious programs that operate remotely) at 3.9% and malware at 2.7%. The new generic extensions concentrate more spamming and phishing practices. Although DNS abuse has been a central topic of discussion between the bodies representing the stakeholders of the Internet community for five summits now, positions still diverge on the measures to be taken to curb these harmful practices. Here again, the expectations of the community at this summit were high.

The GAC, the body that represents governments, has already supported the idea of a dedicated PDP on this topic. It advocates for a holistic approach that addresses all extensions, existing and future. GAC highlighted the work of the SSAC, the Security and Stability Advisory Committee, which advises the community and the ICANN Board on issues related to the security and integrity of the Internet’s naming and addressing systems. Indeed, it published an advisory prior to ICANN70 urging the Board before launching the next round of new gTLDs to commission a study of the causes, responses and best practices for mitigating domain name abuse proliferating in the new gTLDs in the 2012 round. To their credit, they also made a series of recommendations to the ICANN Board, ranging from the systematic presence of security experts in all future contract negotiations to an ePDP (expeditive Policy Development Process).  As for Gnso, it is continuing consultations for the moment without ruling out the use of a PDP.

And the ePDP phase 1 and 2 on access to registration data

Another topic, another PDP process, the ePDP in connection with the GDPR for access to domain name registration data. Initiated in 2018, it was intended to replace a Temporary Specification that involved redacting personal data from freely available registration data of generic names. Phase 1 of the ePDP, not finalized at this time, is intended to replace the Temporary Specification with a future-proof provision. Phase 2 aims to create a standardized data access system for legitimate applications commonly referred to as SSAD. This phase has now reached the end of the roadmap, as it is now in the hands of the ICANN Board of Directors after the Gnso has approved all the provisions formulated by the working groups that have worked on this subject, even those that did not reach consensus. The Gnso assumed this position under the pretext that it was necessary to take its responsibilities and that the recommendations were a whole, a breach of the process of creating new policies that normally wants to be consensual and that led the ALAC (At-Large Advisory Committee) that represents the end users to express concerns, the IPC (Intellectual Property Constituency) that represents the interests of the intellectual property community even going so far as to ask not to continue with the review of the recommendations. The ICANN Board has simply launched an Operational Design Phase to consider the operability of the future system and intends to take a position on the recommendations at a later stage.

A new PDP on domain name transfer policies

Another PDP process was officially launched at ICANN70 to revise the rules for domain name transfers: transfers between registrars and transfers between two registrants. The latter aims to simplify, secure and make name transfers more efficient. A vast project that could extend over several years…

Concerns about the concentration of the sector

Indicative of the concerns of the Internet community, the public forum this year was marked by many questions around the concentration that is accelerating among the players of domain names. The latest is Ethos Capital, a private equity firm founded in 2019, which after buying the operator of .ORG, PIR, has just taken over Donuts, which manages no less than 242 new generic extensions and had recently acquired Afilias, which is among other things manager of the extension .INFO. The community has expressed concerns about these new players whose expectations are not necessarily in line with one of ICANN’s totems, which is to defend competition, trust and consumer choice. ICANN, for its part, does not see a problem in this phenomenon, which has become a trend, because these mergers trigger very closely supervised procedures for analyzing and approving the changes that are brought about. 

ICANN70 has highlighted the fact that ICANN is looking at a number of potentially high-impact topics in domain name management, most of which are about to be materialized into new policies that Nameshield will implement for its customers. Beyond this framework, Nameshield, an independent French player, has already implemented solutions that provide answers to the problems that some of these policies must address. Do not hesitate to reach your consultant with your needs so that we can study together the solutions that we can already bring.

The historical operator of the .UK Nominet in troubled waters

The historical operator of the .UK Nominet in troubled waters
credit image: www_slon_pics

This Monday, March 22nd, at 5:15 pm CET, Nominet, the historical registry in charge of the extension of the United Kingdom, the .UK, announced that the motion aiming to dismiss five members of its board of directors, including the current CEO Russel Haworth and Chair Mark Wood, was approved by 52,74% of the members who expressed themselves in this consultation.

According to its statutes, when a motion is supported by a majority of its members, Nominet must organize a consultation of all its members. Thus, this Monday, March 22, an Extraordinary General Meeting (EGM) was convened to rule on the motion carried under the banner PublicBenefit.uk pushed by Simon Blackler, CEO of the hosting company Krystal, who asked to organize a vote to remove five members of the Nominet board. Among those targeted by the motion were the CEO Russel Haworth and the Chair Mark Wood. A motion with serious consequences for the organization.

At the roots, decisions and actions that have displeased

At 17:15 CET the results of the consultation were announced. 740 members of the registry operator tipped the balance toward this motion, leading to the immediate departure of the board members.

At the roots of the protests was a growing dissatisfaction among some members that crystallized around decisions and communications of the dismissed Board that could give the impression that the registry operator was increasingly turning away from its original foundation as a non-profit organization with public interest commitments to an overly commercial orientation.

Among these decisions, commercial efforts to diversify the activity of Nominet financed by the increase of the prices of the .UK and the reduction of the charitable contributions. Another thorn pointed out by those opposed are the salary increases for members of the board of directors while the operating profits of the organization have fallen over the same period. But without a doubt, the spark that set off the whole campaign came from the brutal closure of Nominet’s online members’ forum at the last annual meeting when CEO Haworth used, in his words, “the wrong tone”.

The management in place had presented a roadmap in the form of a mea culpa a few days before the vote. It consisted of seven major commitments: a freeze on the price of the .UK extension, a freeze on board members’ salaries until the end of 2022, a £20 million investment plan in the operator’s infrastructure, a public interest program focused on young people’s digital problems with £4 million dedicated within three months, the implementation of a new exchange tool for its members, the launch of a Registry Advisory Council (RAC) of elected members who will be able to give their opinion on the policies conducted and greater transparency on the organization’s finances. However, this has not been enough.

What consequences for the operator

Nominet is a major player in the Internet address ecosystem. Their market share of 8.07% of all web addresses in country codes testifies to this. Nominet claims 17,568,576 registered addresses in its extension, which places it in fourth place after .CN, .TK and .DE. The difficult situation faced by the operator is anything but insignificant.

Today, Nominet finds itself with an interim board with an interim chairman, one of the remaining non-executive directors and no CEO. Six unseated board members have chosen not to resign and stated that they will “work on a change of strategic direction”. Nevertheless, they could be blamed for their participation in the decisions taken over the past several years that have led to this situation. A difficult situation for the organization. The former management suggested that this motion could destabilize the organization permanently and perhaps even lead to a split in its activities.

For now, two statements indicate the direction Nominet is likely to take. The first comes from interim president Rob Binns, who sent an email to Nominet members late Monday, shortly after the results were made public:

“I am writing to inform you that the EGM motion passed,” he said before promising that the board had “heard the clear message from the membership and that Nominet will change.”

“The board’s immediate priority is stability, starting with Nominet’s governance and leadership while continuing with the seven-point plan and beginning to address the issues raised over the past few weeks.”

The coming weeks will be crucial for the future of the organization. It will be necessary to renew the vacant positions at the head of the organization and to find the levers to ease the internal and external tensions and worries. It is legitimate to question whether the roadmap left by the former management is the right one, especially since Publicbenefit.UK had other proposals and also had the ambition to push a second motion that was not validated, which consisted in appointing two interim directors – the former chairman of the BBC Trust, Sir Michael, and industry veteran Alex Pawlik, director of RIPE, a historical regional IP address registry. From the perspective of replacing vacancies these people may come forward and when you look closely the proposals from Publicbenefit.UK are not far from the above. Let’s hope that reason will prevail in a compromise. There is no doubt that this is the best thing we can wish for this historical central player in the ecosystem of Internet addresses whose missions and stability are central to the DNS as a whole.

New document : 5 minutes to understand SSL / TLS certificates

5 minutes to understand - SSL/TLS certificates - Nameshield

An SSL (Secure Socket Layer) or TLS (Transport Layer Security) certificate is a digital certificate that authenticates a server (most often a web server) and encrypts the data exchanged with it. The data is thus exchanged in confidence between two actors whose identity is known. The data exchanged cannot be spied on or altered by a third party: confidentiality and integrity.

Download this document “5 minutes to understand: SSL / TLS certificates” on Nameshield’s website.

Download

New document available on the Nameshield’s website: “5 minutes to understand – Abusive domain names registrations

5 minutes to understand - Domain names - Nameshield

The digital world is in perpetual evolution and every days, new domain names are registered around the world.

Among these new registrations, some can potentially affect your notoriety, your activity, and your results. Fraudsters, through these abusive domain names registrations, seek to benefit from your notoriety as quickly as possible.

Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, the different practices of abusive domain names registrations that can affect your brand and the actions to take depending on the infringement caused to the brand.

DOWNLOAD

New document available on the Nameshield’s website: “5 minutes to understand – Data theft of a website

5 minutes to understand - Domain names - Cybersecurity - Data theft - Nameshield

Every day, new cyberattacks are threatening companies’ defense systems, and further weaken relations with web users, particularly on e-commerce websites. Identity theft and data theft have become common.

The risks of a malicious person intercepting the data transmitted by the web user on your website and more generally all the information transmitted between the browser and the server of your website ,are increasing significantly.

Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, the solution to implement against these risks.

DOWNLOAD

Firefox 83 launches HTTPS-Only mode

On November 17, Mozilla released the version 83 of the Firefox browser, promising improved performance in terms of page loading and browsing responsiveness, as well as a significant reduction in the memory used.

But above all, Mozilla introduces a brand-new security feature to the small world of browsers, an “HTTPS-Only Mode” option to limit browsing to secure HTTPS* connections only.

Firefox 83 launches HTTPS-Only mode
Image source: Mozilla Security Blog

Mozilla is pushing it further regarding the desire of major browsers to pass HTTPS as the default browsing protocol instead of the unencrypted and therefore fully visible HTTP.

Which display during browsing?

When the option is activated, any web page that does not have an SSL/TLS certificate (allowing the HTTPS and the security padlock icon to be displayed in the browser address bar) will be preceded by the warning message below, which is restrictive for web users.

Firefox 83 launches HTTPS-Only mode
Image source: Mozilla Security Blog

What to expect in the coming years?

If the option is not yet activated by default, Mozilla’s management indicates that it expects HTTPS to become the standard for browsing the Web. Driven by the successive evolutions of browsers and their increasingly obvious displays of a lack of security, more and more websites are migrating to HTTPS by default. It is likely that browsers makers will decide to completely depreciate HTTP connections in the near future, making HTTPS the default protocol for Web browsing.

How can companies be prepared?

Most companies have already begun the migration of their website(s) to the HTTPS by default. It is important to maintain an exhaustive inventory of the company’s websites and pages and to control the associated SSL-TLS certificates, of which the main risks are renewal errors and poor implementation. It is essential to set up clear procedures and to associate to them a good communication towards the interlocutors in charge of the websites. Actors such as Nameshield are there to accompany you in this process. They have the expertise and tools necessary to simplify these tasks and reduce the risk of error.

New document available on the Nameshield’s website: “5 minutes to understand – Domain names: which procedure?

5 minutes to understand - Domain names - Procedure - Nameshield

Names’ holders must protect their brands and domain names against fraud and abuse just as they would protect any other valuable asset. The infringement of your domain name weakens the strength of your brand.

If, despite defensive registrations, which are a first line of defense, you find out that a third party has registered a disputed domain name, procedures exist to stop the infringement of your trademark and stop the damage.

Find in this “5 minutes to understand” document, available for download on the Nameshield’s website, these different dispute resolution procedures related to domain names.

DOWNLOAD

The dangers of Wildcard certificates

wildcard certificate - TLS/SSL certificates
Image source: skylarvision via Pixabay

TLS/SSL certificates are used to authenticate servers (mostly Web) and encrypt traffic between websites and users. Thus, they ensure the integrity of the data exchanged and prevent data spying. The digitalization of the company and the world in general, as well as the browsers’ desire to impose HTTPS:// by default, have multiplied exponentially the need for certificates.

To meet these growing needs, the wildcard certificate (*.domainname.com) is increasingly being considered by companies. While it has some advantages, particularly in terms of costs reduction and flexibility, it is important to be aware of the disadvantages in order to choose the right certificate wisely. A brief overview of the wildcard certificate.

What is a wildcard certificate?

A standard TLS certificate secures an explicit host name (CN for Common Name or FQDN for Fully Qualified Domain Name) defined in its metadata. For example, Google holds a certificate for mail.google.com.

  • This certificate is only valid for: https://mail.google.com/
  • It cannot be used for: https://google.com/ – https://images.google.com/ – https://my.mail.google.com/

In other words, the host name must be an exact match. If you try to use this certificate on https://my.mail.google.com/ you will get a certificate error from your browser.

A TLS wildcard certificate is different. As its name implies, it uses a generic match rather than an exact match. This generic match is represented by “*” in the CN and covers all subdomains of the same level. Example with the *.google.com certificate.

  • This certificate is valid for: https://mail.google.com/ AND https://images.google.com/ as well as all possible subdomains of google.com.
  • It cannot be used for: https://google.com/ (without subdomain) or https://my.mail.google.com/ (the subdomain level is not the same).

The practical side of the wildcard certificate?

In some situations, the wildcard certificate is very useful. A host that proposes websites for different clients, hosted on a shared server, and accessible through different subdomains… client1.mysite.com, client2.mysite.com, client3… It is less practical, technically more complicated and de facto more expensive to ask for a new certificate for each client that registers; the simplest option is a wildcard certificate for *.mysite.com, a unique certificate that will cover all clients. The case is identical for a company that wishes to access its websites through FQDN derived from the same domain and hosted on the same web server, *.mycompany.com. So far, everything is okay.

But then, what is the risk?

In the cases above, all sites are hosted on a single server. In large companies, or for major websites, hosting is often more complex and on different servers. Let’s take again our example of Google with images.google.com and mail.google.com, these two applications are linked to different services of the company, hosted on different servers and managed by different technical teams. This kind of organization is extremely frequent in the company. And this is where the security of wildcard certificates stops.

The problem with wildcard certificates, and to a lesser extent with certificates containing multiple entries (the famous SAN, Subject Alternative Names), comes from the fact that they are deployed on several servers. Indeed, to ensure the security of a TLS/SSL certificate, it is absolutely necessary to protect the private key associated with the certificate. Ideally, it should be stored in a vault or in a HSM. When a certificate is installed on several servers, the associated private keys circulate, increasing the exposure to the risk of compromise.

Case of a compromised certificate

In case of a compromised certificate, or an error on the certificate (renewal problem), it is recommended to intervene quickly to limit the damage caused. Application for a new certificate (or renewal), installation of the new certificate and, if necessary, revocation of the compromised certificate.

In our example of creating websites on a single server, this is not a problem. We have only one server, it has been compromised, the stolen/expired/compromised certificate only works for this one server; we have limited the damage as much as possible.

In a “several servers” scenario, if the certificate of only one of the servers is affected, it becomes compromised on all of the servers, which will have consequences on all of them and require a much wider intervention to repair the damage, most often in an emergency, and assuming that all of the affected servers are identified. Indeed, it is not uncommon for the certificate to circulate within several teams and to be installed without being listed on a certain number of servers. The impact can be important.

Taking our example of Google. Let’s imagine that only the images.google.com server has been hacked and that mail.google.com has not been affected. The certificate for images.google.com being a wildcard certificate for *.google.com which is common to mail.google.com, the cyber-attacker having compromised the images service has by rebound usurped the identity of the mail.google.com server and can intercept the traffic of the mail service while this server has never been hacked!

Good practice: one TLS/SSL certificate per server…

In our last example, if we were to have two certificates instead of one, with each server having only access to its own certificate, we would have limited the risk. In an ideal world, each certificate should only be used for one server (or a homogeneous cluster of servers). Different services on different servers should have their own certificates, generally not wildcard certificates.

A wildcard can be used if you have a lot of host names, of subdomain type, pointing to the same service on the same server. Be careful however that this generic certificate does not also cover host names pointing to other servers, in which case each service should have its own certificates.

Lastly, if you have a few host names pointing to single servers and everything else on a single service, then it is better to disassociate the host names. For example, you may have a certificate for login.mysite.com and a (wildcard) certificate for *.clients.mysite.com. On this last example, if the number of clients is fixed or clearly defined, it is better to go for a certificate with a precise SAN list, to better control secure host names and not allow the httpS:// on uncontrolled host names.

Conclusion

The option of a wildcard certificate exists and it is a good thing for some very specific needs. But in practice, there should never be a need to install a wildcard certificate, nor should the same certificate be installed on different servers not built in cluster.