Nuclear Winter, freeze all WHOIS projects.

While everyone is struggling with warnings from the EU Data Commissioners and the UN Rapporteur for the right to privacy during ICANN 58 in Copenhagen, we actually must look ahead.

As mentioned before, many of the ICANN policies rely on the WHOIS. Most likely this will turn out to be a single point of failure.

The current policies we will need to revisit them when we get more clarity, and it looks like ICANN is going to work on an update on the legal review from 2015. That review wasn’t too great, to begin with, but let’s not go there.

In no particular order, the following projects need to be frozen and see if the scope and the objectives are still correct.

  • Thick WHOIS Migration
    Translation and Transliteration of Contact Information
    WHOIS ARS
    Crossfield validation
    PPSAI

Thick WHOIS Migration
Though I do not think this one will ever happen, it is perhaps good to point out that Registrars outside of the EU but with privacy laws need to check if they can transfer data to the USA.
For example, Turkey has adopted privacy laws very similar to the EU GDPR in March 2016.
Given the current political climate, it seems like a country where breaking the law has severe consequences not only monetary ones.

Translation and Transliteration of Contact Information
Currently in the IRT phase. But how sound is translating WHOIS information to a public directory when publishing the original data is already illegal, provided it is personal information?
This project needs to be frozen till there is more clarity and have the scope adjusted.

WHOIS ARS
This project mandated by the GAC and in operation without a PDP in its current form is illegal.
ICANN uses several third parties to download WHOIS data from Registrar WHOIS servers and processes the data on several levels for data correctness.
ICANN emails and performs auto calls to Registrants, to verify data correctness.
Within the RAA 2013, ICANN can do this. However, due to the poor setup, several EU laws are being broken. These third parties are not privacy shield certified (just to name a problem), as such in the current state this project is illegal. Not to mention they most likely never looked at other countries who also have privacy laws.

To be clear here, this project can operate legally if ICANN complies with the EU law.
This project should be frozen till all the legal requirements have been met.

WHOIS Crossfield validation

https://community.icann.org/display/AFAV/Documents
Though most vendors proposed by ICANN are privacy shield certified, we need to know if they just comply on paper or also in reality. This is a big difference and fundamental to Privacy Shield.
Furthermore, we need to know if this is going to violate other countries privacy laws as most of them are modeled around the EU Directive 95/46/.

In addition to this. Afilias announced that since April 7, 2017, postal code is no longer a required field as there countries out there that do not have a postal code.

The Registry for Dot Africa states in their policies that, street address and postal code are optional. Most likely due to the fact, there are countries in Africa that do not have them.

This makes cross field validation nearly impossible, and most likely bad actors/cyber criminals will use this blind spot and provide registrant information from Africa to avoid cross field validation.

This project needs to be scrapped.

PPSAI- Privacy/Proxy Services Accreditation Implementation
On the one hand, I think this work should continue, on the other hand, we might face some huge changes.
What if we no longer publish personal data in a public directory? Then the entire business model for third party privacy providers goes under the bus, and there is no need for those folks.
What if we require third party privacy providers to be accredited and require annual fees paid to ICANN?
This would collide with the The Universal Declaration of Human Rights Article 12 the right to privacy. In this scenario how could these providers even charge money for their services?
Operating a privacy service simply costs money.

Perhaps it is best to freeze this one also, till we have more clarity.

Theo Geurts

The EU GDPR, The wrong Equalizer?

We can predict with a large certainty the public WHOIS will be a thing of the past.

This will create issues for two group and a few more, but let’s focus on these two for now:
LEA’s (Law Enforcement Agencies)
Commercial cyber crime fighters, perhaps not the best choice to call them this but as they are very diverse, this seems to cover most of them.

The EU GDPR is somewhat (okay very often) characterized as the boogeyman invented by folks who are so pro-privacy that they lost sense with reality.
This is a misconception. Yes the EU GDPR has been created by an army of lawyers and legal folks that are downright scary in numbers, but they were very much in touch with reality during the process.

The EU GDPR has been forged by the EU directive 95/46/ec and has been challenged in court on a national level and European level by many times. The courts were always trying to strike a balance between privacy and the needs for LEA’s.
Cybercrime is not just something that only happens at the DNS level it is happening on all levels in our society.

Many companies outside of the DNS have been dealing with the EU directives for years and embedded them into their processes when it comes to data collection and data processing. And lets not forget they dealt with Cyber Crime and LEA’s, so far, nothing new.

During the creation of the EU GDPR, many LEA’s were consulted, and this is reflected within the EU GDPR.
For LEA’s there are enough provisions to continue their work.

Commercial cyber crime fighters, what about them?
At first glance and due to one-sided information it looks like these folks are screwed big time. However, this is not the case. The EU GDPR has room, but it requires a legal framework and contractual obligations. I keep this very broad as I am no lawyer, but when you dig through the EU GDPR, you will discover room to operate.

What Commercial cyber crime fighters should not do.
Look at ICANN for help or the EU Data commissioners.
ICANN has a horrible track record when it comes to privacy in general. Not intentional but due to circumstances, but it is what it is. So asking ICANN is not the solution, ICANN requires tons of help regarding the subject of privacy themselves. Like the blind leading the blind here.

EU Data Commissioners
From a high-level perspective, these folks and the Article 29 WG can help. But the problem is that we are dealing with very specific purposes and operational matters, and they cannot zoom into a micro level. And on a macro level, you get the idea that nothing is possible and privacy is blocking everything and anything.

What Commercial Cyber Crime fighters should do.
As a Registrar, we run into practical GDPR issues all the time. The solution? Consult a lawyer that is well versed when it comes to the GDPR and knows the DNS industry well.
Costs money for sure, but hey our business depends on it. And don’t forget many companies outside the DNS already did this in the past, again nothing new here.

The only thing that might be new here is the sudden change in thinking on an ICANN level and a boatload of people who are in desperate need for tailor-made solutions. Again ICANN will not help you out there, neither will the RDS WG at this stage. When it comes to the RDS WG, you will need to bring that knowledge to the table and the solutions. You might get lucky that someone will join us that has deep knowledge about fighting abuse on an operational level and has in-depth knowledge about the EU GDPR and knows exactly what to do.
Personally, I wouldn’t count on that; I would try to get ahead of this.

Personal Experience.

So far my interaction with several lawyers gave me a positive feeling when it comes to the EU GDPR. Just when you are about to smash your head against the wall while yelling:”this cannot be done! or this is going to cost us a fortune!” The lawyers so far always came up with a solution or interpretation of the EU GDPR that turned the issue in a workable solution, ie the EU GDPR is not so black and white as it appears, it actually appears very well balanced, you just need to know the nuances.

If you need a lawyer that knows the EU GDPR and DNS drop me a line, I have worked with several of them over the last few years, not to mention the last few weeks 😉

Theo Geurts ICANN Registrar.

The complete mess the WHOIS created, a Registrar perspective.

The public directory we call a WHOIS, where we publish registrant data of domain name owners, is a MESS.

 

Sure LEA’s and other crimefighters have a different opinion, and it is one I share in the sense, that abuse is a huge problem and abuse must be taken down. Often in these discussions, when we talk about the unlimited access to registrant data and that it also has to comply with privacy laws the discussion, usually goes the wrong way and often we can hear or read, the Registrars are pro-crime, or worse they condone child porn. Arguments to remain the current status quo, wich is understandable, but the reality is Registrars are mostly companies who try to run a business in a responsible manner. And now and then this becomes acknowledged by parties who know we hate abuse just as everyone else.

So let me post some facts and leave the LEA arguments outside of this scope.

Publishing personal data or registrant info in a public directory creates the following issues we deal with on a daily basis.

To understand this better you have to realize that ICANN publishes zone files that contain newly registered domain names. There are folks who scrape this info and scrape WHOIS info on a fully automated basis and resell this info or use it for their shady practices. Yes, this includes personal information. And no, they have no right, but they ignore every privacy law that there is out there and every disclaimer a Registrar has in place about the terms of usage.

When you register a domain name and get yourself some hosting and other services not much later, you will get the following in your email box.

Domain name renewal notice. This is not a renewal notice at all; it is a shady SEO company that urges you to pay them money to get listed in some vague directory to boost your SEO. The result, confused registrant, calling their Registrar support desk. We are losing money here.

Hosting notice. Within a few hours, our customers get an email from a shady hosting company that offers 99 Cent Hosting with an uptime of 100%. Our support teams have endless discussions with our customers explaining why we charge more, why we have better service, and it is just unreal when you hear these conversations. Again money down the drain.

Spam lists. Your information will be resold, spammers will gladly scrape your info, and a day later your email box contains emails ranging from Viagra to shady investment deals and marriage proposals from Russia.

Phone calls. Later in the week, you will get robot calls from companies trying to sell you whatever. Fake Microsoft employees are trying to trick you and a lot worse. And let’s not forget SMS messages.

Viri, malware, phishing. Enough said, hope you have a good virus scanner and let’s hope you do not get hit by some crypto locker ransomware.  If your computer gets infected by ransomware it is best to pay according to the FBI.

ICANN and policies and the current issues.

  • As a Registrar, we have to verify your email address.
  • As a Registrar, we have to email you an FOA when you want to transfer your domain name.
  • As a Registrar, we need to email you if you want to change the ownership of your domain name for whatever reason.

In November 2015 Registrars were hit hard by phishing emails. These emails looked like real emails Registrars send for the above reason. However, these emails carried a payload in the form of Ransomware.

For years we, been educating our customers not to click the cute teddy bear in emails and throw away email if it looks suspicious.

Since November 2015 our means of communication have taken a huge hit, processes come to a total standstill, our support desks are dealing with increased overhead. And the phishing continues, and every few months some Registrar takes a hit from these targetted phishing attacks. Domain names get suspended as our communication is longer trusted. Mass frustration.

We implemented DKIM, we use PGP to sign our emails, but it is simply not working as most folks have no idea what PGP is.

I understand the LEA arguments, but the above is also a reality, and it is bad, it is ugly, and it is all due to the fact we have WHOIS system that shouldn’t have existed in the first place.

Perhaps ICANN should throw some money towards the abuse problem. As it is now, we have huge discussions, over what is, in my opinion, a penny war. But it is pennies what we earn, so let us take that issue out of the equation, and I am pretty sure the discussion with LEA’s and other parties will go much smoother.

 

 

 

 

ICANN’s WHOIS ACCURACY PROGRAM SPECIFICATION, a closer look.

Dissecting the Registrar Accreditation Agreement 2013 part 1

Now that the RAA 2013 is up for public comments on ICANN’s website I decided to zoom in on some parts of this new agreement.

It’s a been long road, 18 months of negotiations between the domain name Registrars and ICANN is now over. As written many times before on this site, one of the most controversial and debated part of the entire RAA.

What the FBI and other law enforcement agencies wanted

Under ideal circumstances the law enforcement agencies would have loved a domain name registration system, where you as the domain name registrant would have to visit the domain name Registrars office, and after handing over a boatload of documentation you wouldbe on your way home while your domain name Registrar would run several background checks, and perhaps in a month or two your domain name would be registered or perhaps if the background check did not produce enough information. you would have to visit the Registrar again so the Registrar could take some DNA samples CSI style.

What the rest of world wanted

The Registrars and other stake holders didn’t embrace the above vision and wanted less intrusive methods of registrant verification. So after 18 months we have something called :”WHOIS ACCURACY PROGRAM SPECIFICATION”. An end result that did not make the LEA‘s jump for joy.

Let’s zoom in on this verification system and theorise about the implementation and the implications for you as a registrant.

Registrar shall validate:

  • Validate the presence of data for all fields required under Subsection 3.3.1 of the Agreement in a proper format for the applicable country or territory.
  • Validate that all email addresses are in the proper format according to RFC 5322 (or its successors).
  • Validate that telephone numbers are in the proper format according to the ITU-T E.164 notation for international telephone numbers (or its equivalents or successors).
  • Validate that postal addresses are in a proper format for the applicable country or territory as defined in UPU Postal addressing format templates, the S42 address templates (as they may be updated) or other standard formats.
  • Validate that all postal address fields are consistent across fields (for example: street exists in city, city exists in state/province, city matches postal code) where such information is made available to Registrars.
  • With the above in mind we can conclude that the WHOIS will have less odd elements as we know it today. Telephone numbers will have one and the same format. The last validation bullet (matching data) is one that is very intresting Not all countries use postal codes and that is just for starters.

Registrar shall verify :

  • The email address of the Registered Name Holder (and, if different, the account holder paying for the Registered Name) by sending an email requiring an affirmative response through a tool-based authentication method such as providing a unique code that must be returned in a manner designated by the Registrar, or
  • The telephone number of the Registered Name Holder (and, if different, the account holder paying for the Registered Name) by either (A) calling or sending an SMS to the Registered Name Holder’s telephone number providing a unique code that must be returned in a manner designated by the Registrar, or (B) calling the Registered Name Holder’s telephone number and requiring the Registered Name Holder to provide a unique code that was sent to the Registered Name Holder via web, email or postal mail.

What the Registrar has to verify is pretty straight forward, and as you can read no DNA samples require verification to have your domain name registered, just your email address.

Return to sender.

What if the verification does not happen ? A registry like DK Hostmaster has an email verification system in place for many years now. One is an email that contains your login to activate the domain name and if your email is down for some reason you will receive a letter from the registry that also contains your login details. If you do not activate your domain name the domain name will simply not resolve and stays reserved for 30 days and then the registration will be undone.
A simple system, yet 10% of all the registrations fail when it comes to the ccTLD .DK. That is a massive amount of domain names when you would apply such a system for .com or .net. However ICANN has come up with a different solution.

In either case, if Registrar does not receive an affirmative response from the Registered Name Holder, Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If Registrar does not receive an affirmative response from the account holder paying for the Registered Name (when that information is different from the Registered Name Holder), Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.

So here we have it and let’s see how that one works in the real world.
Lets assume the Registrar works with a reseller model, the flow would go like this:

Domain name gets registered and an email is send to the registrant and the reseller.
Registrant does the verification and also the Reseller and both have been verified.
Much rejoicement and happy people everywhere.

In the scenario where the registered domain name holder/registrant does not go through the verification process the domain name gets suspended after 15 days. If the reseller does not respond the Registrar will verify the data manually, but the domain names does not get suspended.

More fun.

If the Registrar discovers that the information is incorrect then the Registrar is required to re-verify the data.
Sounds simple, in reallity however this is going to be alot of fun. Registrars currently need to send a so called WDRP email to either the registrant or the admin contact. Currently it is only required to send the email regardless if the email bounces back or not. With this provision if it bounces back or the email does not get delivered the re-verification process kicks in. The ICANN text is as follows :

Registrar shall either verify the applicable contact information manually or suspend the registration, until such time as Registrar has verified the applicable contact information. If, within fifteen (15) calendar days after receiving any such information, Registrar does not receive an affirmative response from the customer paying for the Registered Name, if applicable, providing the required verification, Registrar shall verify the applicable contact information manually, but is not required to suspend any registration.

Here it says the Registrar does not have to suspend the domain name. However the next section says :

Upon the occurrence of a Registered Name Holder’s willful provision of inaccurate or unreliable WHOIS information, its willful failure promptly to update information provided to Registrar, or its failure to respond for over fifteen (15) calendar days to inquiries by Registrar concerning the accuracy of contact details associated with the Registered Name Holder’s registration, Registrar shall either terminate or suspend the Registered Name Holder’s Registered Name or place such registration on clientHold and clientTransferProhibited, until such time as Registrar has validated the information provided by the Registered Name Holder.

Willful, what can be considered willful and not willful ? There is the obvious part where a registrant tells the Registrar to take a hike, and then there is the not so obvious part when you have to deal with a company with multiple departments and decision makers. Needless to say this could use some clarification.

So it is time to get your email addresses up to date, together with your other information and check for yourself if you would pass the verification. Afterall it would be a shame if one or perhaps all of your domain names will get suspended due to a bounced email.

All Registrars who wish to sell all the new gTLD domain names are required to sign the RAA 2013 and i expect the new RAA 2013 to go live within a few months from now if not earlier.