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, and +glynmoody on Google+

Filed Under: email, encryption, gdpr, germany, transport layer encryption

Reader Comments

Subscribe: RSS

View by: Time | Thread

  1. identicon
    Anonymous Coward, 8 Feb 2019 @ 6:51am


    Authentication is really important too, and not listed in the article. Here's some relevant text from the linked PDF:

    EMLREQ_4: DANE (incoming): In compliance with the regulations of the Internet Assigned Number Authority (IANA), the domain(s) used by the EMSP [E-Mail Service Provider] MUST be protected by DNSSEC in accordance with [IETF RFC 6781]. Furthermore, the EMSP MUST publish information of his certificate in the DNS record by using DANE/TLSA in accordance with [IETF RFC 6698].

    EMLREQ_5: DANE (outgoing): Using DNSSEC in accordance with [IETF RFC 6781], the EMSP MUST check all connections to other EMSPs to determine whether or not the information on using DANE/TLSA has been published in the DNS record of the receiving EMSP in accordance with [IETF RFC 6698]. If the relevant information is present, the authenticity of the connection MUST be verified based on this information and canceled if the certificate information does not match the cryptographic information presented by the receiving EMSP or if no transport security (e.g. STARTTLS) is presented at all.

    EMLREQ_6: PKI certificates: All the certificates that the EMSP uses for communication with other EMSPs and the user SHOULD be issued by a certificate authority (CA) that was certified according to [BSI TR-03145].

    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).

Add Your Comment

Have a Techdirt Account? Sign in now. Want one? Register here

Subscribe to the Techdirt Daily newsletter

Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Report this ad  |  Hide Techdirt ads
Recent Stories
Report this ad  |  Hide Techdirt ads

This site, like most other sites on the web, uses cookies. For more information, see our privacy policy. Got it

Email This

This feature is only available to registered users. Register or sign in to use it.