German Data Protection Authority Says GDPR Requires Email To Use At Least Transport Layer Encryption
from the but-why,-is-not-entirely-clear dept
As Techdirt has reported, the EU’s GDPR legislation certainly has its problems. But whatever you think of it as a privacy framework, there’s no denying its importance and global reach. That makes a recent ruling by a data protection authority in Germany of wider interest than the local nature of the decision might suggest. As Carlo Pilz reports in his post examining the case in detail, the Data Protection Authority of North Rhine-Westphalia (Landesbeauftragte für Datenschutz und Informationsfreiheit Nordrhein-Westfalen — LfDI NRW for short) looked at what the GDPR might mean for email — in particular, whether it implied that email should be encrypted in order to protect personal information, and if so, how.
The LfDI NRW made a fundamental distinction between encryption at the content level and encryption at the transport level for the transmission of emails. The former encrypts content and attachments, using technology such as S/MIME and OpenPGP. However, the metadata associated with an email is not encrypted. With transport layer encryption, both the content and the metadata is encrypted. Pilz explains:
LfDI NRW therefore assumes that without exception at least transport encryption must always be implemented. As mentioned above, such a mandatory encryption obligation does not result from the GDPR. One could therefore argue that this view goes beyond the requirements of the GDPR. In its assessment, the authority may assume that transport encryption is now the “state of the art” mentioned in Art. 32 para 1 GDPR. This could be supported by the reference to the European providers. Nevertheless, Art. 32 para 1 GDPR provides, in addition to the feature “state of the art”, for further criteria which must be taken into account for the measures to be implemented, such as in particular the risk of varying likelihood and severity for the rights and freedoms of natural persons. Thus, under the GDPR, controllers and processors should still be able to assess whether encryption of the data is absolutely necessary on the basis of these characteristics. Unfortunately, the opinion of the authority does not go into the individual criteria mentioned in Art. 32 para 1 GDPR in detail and does not justify its opinion.
So the newly-published position of the German data protection authority is not exactly clear as to why it thinks transport layer encryption must be used, although it does specify which standard must be followed: BSI TR-03108-1: Secure E-Mail Transport (pdf). It also mentions that transport layer encryption may not be enough when dealing with particularly sensitive personal information. This includes “account transaction data, financing data, health status data, client data from lawyers and tax consultants, employee data”. The problem here is that even though encrypted in transit, the emails are stored in cleartext on the servers. To address this, LfDI NRW says that additional security measures are required, for example using end-to-end encryption, or even falling back to physical postal delivery of highly-sensitive documents.
Because of the way GDPR is enforced, it’s worth noting that the opinion of the LfDI NRW does not automatically determine the policies everywhere in the EU. It may influence the thinking elsewhere, but it’s possible that other data protection authorities in the EU might disagree with this interpretation — in which case the Court of Justice of the European Union would be called upon to adjudicate and offer a definitive interpretation. However, at the very least, the LfDI NRW’s position indicates that the GDPR is likely to impact when and how email encryption is deployed by companies operating in the EU, along with all the other areas it touches upon.
Follow me @glynmoody on Twitter or identi.ca, and +glynmoody on Google+
Filed Under: email, encryption, gdpr, germany, transport layer encryption
Comments on “German Data Protection Authority Says GDPR Requires Email To Use At Least Transport Layer Encryption”
in other words, basically, everyone to do with security services, politicians, health employees, the entertainment industries and almost everyone else you can think of, except ordinary people, need to be able to access everyone’s emails while no ordinary person is allowed to access emails of the security services, politicians, health employees, the entertainment industries and almost everyone else you can think of! the rich, the powerful and the famous, yet again, will be able to do what they like, while no one else will! talk about the planet being enslaved and controlled by those same ones who write the self-serving laws that screw everyone else!
Re: Re:
Your ability to comprehend what was written is about as good as your understanding of politics, that is biased by extreme paranoia.
Re: Re:
Those are definitely other words, all right.
While on a personal level I agree that all SMTP should be secured by TLS I’m smart enough to know what a pain that would be to enforce. Would all ISPs need to reject non-TLS // non-SSL encrypted traffic on common SMTP ports? Would all white label email providers need to manually secure a gaggle of CNAMEs for their customers?
It’s a good idea, like a law saying everyone must always lock their doors, until you realize the horrendous work involved with enforcing it.
Re: Re:
That’s not terribly hard. The customer domains simply need DNSSEC enabled, and if the white-label provider is the DNS provider they can do it automatically. The MX records will all point to the provider’s domain, which would need a DANE record and DNSSEC.
Re: Re:
There are no requirements on ISPs except to the extent they’re E-Mail Service Providers (EMSPs). ISP-provided email addresses are not very popular these days.
But later:
That doesn’t prevent them from accepting unencrypted mail, but they can’t send it. Users must be able to look at the headers and see the security used.
Authentication
Authentication is really important too, and not listed in the article. Here’s some relevant text from the linked PDF:
In other words: German organisations may send email to people who have insecure setups, e.g. self-signed certs, but it’s recommended they don’t. They are, however, required to securely publish their own certs. Traffic between two compliant servers will be therefore properly encrypted and authenticated (DNSSEC means the DANE record, or the indication there’s no such record, cannot be faked without the proper keys).
Re: Authentication
That’s actually an important distinction.
From reading the article I was under the impression that Germany was saying GDPR mail providers wouldn’t be able to send to a recipient whose server wasn’t configured to properly support TLS. While big providers are mostly TLS now and can reasonably be expected to fix the issue if lacking it became a missing message problem, and the smallest level of private/vanity mail servers are mostly outsourced to hosting companies than can do automated mass updates if needed (like they did for HTTPS recently). But in between those poles is a major problem area. Although individually small there’s a huge swath of generally smallish mail servers that are nominally self administered but effectively unmaintained unless something appears broken to the user. Lots of them would have fallen through a crack because their owners don’t read the tech press, and they do business with Europe infrequently enough that it wouldn’t be an obvious problem.
Re: Re: Authentication
How will the notification requirements act for non-TLS destinations? It’s easy when receiving non-TLS—reject the message, or ensure the "Received:" lines differentiate TLS/plaintext as they usually already do. But senders are supposed to know whether their communications are secure too; it’s too late after the thing’s been delivered, and the sender doesn’t see those headers.
Are providers expected to bounce messages back to the sender and ask whether they really want to send? Log the event and notify the sender? Just store the security-relavant logs waiting for a GDPR request?
It may be a good idea for sending servers to notify recipients, via a separate message, that the message someone tried to send to them was sent insecurely or blocked due to their lack of TLS or proper certificates. Done poorly it could look like phishing.
Re: Re: Re: Authentication
For me it is clear that the LfDI NRW expects that the organizations that fall under its jurisdiction will start supporting “encrypted email transport” (email-over-TLS) soonish. As I see it, the minimum is the ability to receive email over an encrypted connection and a preference to send encrypted.
I didn’t look at the details of the proposal like obtaining, publishing and/or verifying certificates, but it is possible that guidance (rule making) on those aspects will come later. Also the question of how to handle sending mail to servers that don’t support TLS is something where rules can be made, clarified or changed later.
A DPA can only make rules about the handling of personal data. The content of general newsletter (or the average news website) is outside their area of rulemaking.
Re: Re: Re:2 Authentication
I’m pretty sure an email address or name is personal data; by extension, a newsletter’s subscriber list or site’s member list needs to be protected (and it really is sensitive data, at least sometimes).
Re: Re: Re:3 Authentication
You are right there. The content is different from subscriber or reader lists.
I certainly agree with the need to ramp um the security for the e-mail system but it would be interesting to see how they’d enforce such requirements if they were made mandatory considering the Internet goes way beyond the EU.
Re:
Currently it is just one Data Protection Authority giving its interpretation of the GDPR. Personally I think this interpretation is not a surprise at all, just a pointer to current “good practice”; there are more government agencies in the EU recommending TLS encryption for email.
Formally, the DPA can give binding regulations to the companies within its jurisdiction. Currently it is more of a request for public comment, but this interpretation of the GDPR has a good chance to become “the law” for companies in Nordrhein-Westfalen (a part of Germany) in one or two years.
If DPAs in other jurisdictions follow this interpretation, it will become “law” in their jurisdictions too. (I know the DPAs of the EU have regular contact; if they achieve consensus TLS for email may be the EU rule in five years.)
As the DPAs don’t have a say over private email servers (and clients) or servers abroad it will remain possible to continue the bad practice of sending unencrypted email over port 25. 🙂
Re: Re:
That constraint doesn’t seem to have bothered them in any other data protection / data privacy contexts. Why should they start worrying about that now? 🙂
Going Dark
First EFF (and others)’s LetsEncrypt project means that the rate of encrypted web traffic is now sky high. Then the EU’s GDPR may mean that email transport gets encrypted too.
OMG its all going dark!
So, where does this go? It means that the intelligence agencies now need to compromise phones, computers and email servers because the backbone is now largely running transport layer encryption.
Time to invest in companies that sell vulnerabilities.
Re: Going Dark
It’s the invention of the envelope all over again!
And Don't Forget
… to add the mandatory back-door so that all government agencies can read all emails anyway…just convince the users that it is secured…
Content vs. Transport Encryption...
If I understand correctly, Content encryption would be placing your personal letter inside an envelope with TO & RETURN address info written on the outside. Nobody can read your letter but they can determine where it came from, where it is going, when it went there, etc. Transport encryption would then place your envelope inside another envelope without any of the other info on it and hand-carry it to the destination where it would be opened and then delivered to you.
Re: Content vs. Transport Encryption...
The envelope example is nearer transport encryption, the only data visible is to allow routing visible. Anybody with access to the email server can read the content, which was protected by transport encryption between sender and the server, and it is again encrypted for transport from the server to you.
Content encryption, like signal, also encrypts the contents of the envelope so that only the sender and receiver can read the message. With encrypted content, access to the server only gives access to the encrypted message.