European GDPR and personal data processing


#1

On May 25, the GDPR (General Data Protection Regulation) will come into effect.
http://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

Does Let’s Encrypt planned to respect the letter or the spirit of the GDPR?

In summary, this European law create new rights and obligations regarding the processing of personal data:
For individuals, rights to know which personal data is processed, and under some circumstances, the right to refuse the processing, correct the data or ask for the deletion.
For companies processing personal data, the obligation of protection, and to answer the requests of individuals.

In United States, “PII” (Personally identifiable information) often refer to data that can identify a person (like a full name, or a passport number). “personal data” in that legislation is broader: it’s any information linked to a PII:

‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person
Even if the IRSG is in the USA, the GDPR may apply:
This Regulation applies to the processing of personal data of data subjects who are in the Union by a controller or processor not established in the Union, where the processing activities are related to:
(a) the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union; or
(b) the monitoring of their behaviour as far as their behaviour takes place within the Union.

(disclaimer: I’m not a lawyer)

Let’s encrypt store multiple identifier which may be associated to individuals:

  • IP address
  • email address
  • domain name
  • account id

Any data associate to these identifiers must then be considered as personal data.

Here is the list of processing I’ve identified:

  • For the delivery of certificates (account information, certificates requests, …)
  • The information on visitors of letsencrypt.org
  • The https://community.letsencrypt.org/ forum
  • The requests of OCSP responses queried by the visitors of websites using Let’s Encrypt

Other companies with whom some data may be shared:

Information provided:


https://www.discourse.org/privacy

Other relevant link:

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf#page=39

5.5.2. Retention Period for Archive
The CA SHALL retain all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid


#2

Interestingly, I have had to make some changes to my LE setup as a result of GDPR. I don’t do business in the EU and I have never asked any member of any country in the EU to visit my site, nor due to the nature of my offering transact any business in the EU, or really any other country than the US for that matter. I don’t want your data! You are the ones who give it to me. I mean, I don’t really collect any data other than what is in my http log files I keep for audit trail on my static webpage, but by some wacky logic the EU thinks that IPs are private. To avoid the who ordeal I have decided to ‘close up my shop’ so-to-speak and just not let those pesky EU people into my servers (yes, the ones THEY are asking to visit). This apparently has been a common reaction. To achieve this, I have used a multi-layered approach to make it clear they aren’t welcome by first using a geo-DNS resolution policy that won’t return an answer unless it has geolocated within North America and using a second (different) IP block list to whitelist north american IPs and block, by default, everyone else. Whew - crisis averted!

Well, until you consider the extreme secrecy LE has on which IPs they use for validation. It is ironic given the amount of transparency they want of everyone else, but nonetheless it is what it is. However, this means I can’t guarantee they will look up my address from a north american IP/location. That would be quite valuable. However, it has forced me to use DNS validation methods to authenticate, which really isn’t a huge deal, but my DNS provider won’t grant me granular access keys to change the TXT records - the same access key allows changes to all records, which is a bit of a threat, but seemingly a smaller one than the one posed by the EU lawyers. At least I can manage that threat by further auditing the use of that access key and establishing other safeguards to ensure my critical entries in DNS are set correctly and alarm if they aren’t. Or perhaps the DNS provider will grant further granularity to a particular record in the future.

Anyhow, in summary, it would be nice to at least be able to select a region to have LE perform verification from, in light of the common approach of blocking IP ranges from parts of the world others find undesirable to accept IP traffic from.


#3

@chris-1

That’s not practical. Declining to provide information about or control over validation:

  1. Allows Let’s Encrypt to easily change their IPs in the future,
  2. Sidesteps validation issues from users with out-of-date firewall rules, and
  3. Holds the door open to pursue mitigations for BGP hijacking attacks like validating from different points around the world.

While Let’s Encrypt hasn’t taken very much advantage of it yet – though they’re involved in research, and the staging environment does validate from multiple locations – immortalizing the current validation IP addresses is against long-term operational agility, reliability and security.

Can you use CNAMEs or delegations to a DNS service with more granular access controls, like acme-dns?


#4

@chris-1 thank you for your feedback.

not “private”, just “personal data”, and it’s reasonable as a lot of people have a fixed IP. If any website leaks the IP and the name of the person, it’ll be easy to break her privacy on other.

I don’t think it’s a viable solution for Let’s Encrypt, but I understand the cost of implementing the GDPR.

Such option could make attack easier, by forcing the validation to use a certain path.


#5

I appreciate the reference to acme-dns, as I had never heard of it. However, at the moment, it appears it lacks
security features such as DNSSEC. Perhaps that will be added in the future. Nevertheless, with DNS being so commodity these days, it is far simpler to delegate to a PaaS offering, especially considering the price.

Perhaps I miscommunicated a couple of elements. I think LE has every right to use a security by obscurity model, although there is plenty of notable research indicating that security by obscurity really is no security at all. That is how they run their service. I still think you can run that model, but still be able to work with a request that the validation be performed through a region or country. In this case, it would be the region or country in which the website exists and provides service.

Long before GDPR, the Internet was starting to get more customized based on ‘who’ was asking for the same piece of data. If I ask google what the weather is, the first result it thinks the weather is in my area. If I go to netflix and try to login, I get a different set of available titles depending on what country it thinks I am from to comply with their licensing deals.

However, there are also a lot of countries that ban interaction with other countries. Although I admittedly hadn’t given it much thought, perhaps I should have always blocked traffic from countries on the US embargo list. I certainly don’t do any business with them, but never thought much about denying their traffic as it is fairly simple for them to get around if they want, and my server is hardened. However, if LE did validation from one of those countries, I would be unable to validate with LE. I think that is a bug in the LE model and just pointing out that perhaps a flag with some list of regions of which the website operates so validation can be performed by that region would still operate without you supplying the IPs through which you do the validation.

Oh, I wasn’t trying to suggest any possible implementation for LE as a result of the overly-reaching GDPR law (which I think has questionable legal status for those who conduct no business in the EU). I was merely trying to explain the background for which I chose to block all EU traffic. I was just seizing the thread to provide how the GDPR can effect LE users and clients.

If it is so personal, don’t provide it to me! Ultimately, that is one of the ridiculous portions that has gone overboard. There is no reasonable way for me to service an EU request to view content on my site without responding to your IP address. As a side note, there are a lot of interesting articles about how GDPR will be used by criminals to erase traces of their illegal activities by the rights granted to them to force companies to erase items, even as far as IP addresses. The law seems ill-conceived.

However, such an option would reflect realities of how the Internet is getting customized to regions and areas. I know of no attack vector that would permit LE free reign to validate from anywhere within a sufficiently large region that wouldn’t equivalently affect the Internet ‘region’ as a whole.


#6

I’m not able to get into the details of all this here and now, but we are aware of the GDPR. We’ve made some changes to further limit the scope of how we store some information as a result (specifically, optional contact email addresses).

Our general strategy continues to be to minimize the collection of personally identifying information.

Our Privacy Policy continues to be the best source of information about what we collect and how we handle what we collect:


#7

DNSSEC isn’t really necessary within acme-dns as it’s only acting as a temporary validation service that responds to queries – much like a regular webhost acts in port 80 validation – it’s not functioning as a normal DNS Server to manage dns for a domain/subdomain or redirect hosts; it simply serves up the TXT records. You still point to the acme-dns instance, or cname onto it, via your regular DNS servers which can be secured via DNSSEC. DNSSEC on acme would be a nice bonus, but it’s still as-secure-as the port 80 validation.

Very few paid DNS platforms offer granular access to management, and leaving those keys on a server (for automated management) is a giant security risk. acme-dns remains the most secure option for the majority of users.


#8

Not publishing the list of IPs that perform validation has nothing to do with the security of Let’s Encrypt – it’s done for the reasons @mnordhoff listed above.

Processing a user’s IP address to serve requests is legal under GDPR :slight_smile:
Being PII doesn’t mean that it’s illegal to have, it just means that it falls under GDPR rules.