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


Reader Comments

Subscribe: RSS

View by: Time | Thread


  • identicon
    Anonymous Coward, 8 Feb 2019 @ 5:52am

    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!

    reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 8 Feb 2019 @ 6:44am

    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.

    reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 8 Feb 2019 @ 7:03am

      Re:

      Would all white label email providers need to manually secure a gaggle of CNAMEs for their customers?

      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.

      reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 8 Feb 2019 @ 7:12am

      Re:

      Would all ISPs need to reject non-TLS // non-SSL encrypted traffic on common SMTP ports?

      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.

      The user is to be understood as the end user of the infrastructure described here. He uses the services of one or several EMSPs to send and receive his e-mails. At this point, it is not differentiated between sender and recipient role, because from the EMSP's perspective, the same security measures MUST be applied to both roles. The EMSP MUST ensure that the user sends and receives his e-mails in compliance with “EMLREQ_1: TLS (user to EMSP)”. Furthermore, the EMSP MUST inform the user of security-relevant incidents in accordance with the [IT-Sicherheitsgesetz]. The EMSP MUST also provide assistance with regard to IT-security-relevant topics in accordance with “ADDREQ_2: Obligation to provide information” to the user.

      But later:

      The assumption here is that the systems of the individual EMSP communicate via an open network (Internet) and also include communication with non-certified EMSPs. In the communication with non-certified EMSPs, the requirements formulated here are intended to create a condition under which connections generally are as secure as possible. … An EMSP's user MUST be able to find out which of their e-mails are sent to certified EMSPs or received from certified EMSPs

      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.

      reply to this | link to this | view in chronology ]

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

    Authentication

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

    reply to this | link to this | view in chronology ]

    • identicon
      Dan Neely, 8 Feb 2019 @ 8:52am

      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.

      reply to this | link to this | view in chronology ]

      • identicon
        Anonymous Coward, 8 Feb 2019 @ 10:13am

        Re: Re: Authentication

        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.

        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?

        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.

        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.

        reply to this | link to this | view in chronology ]

        • identicon
          MathFox, 8 Feb 2019 @ 12:03pm

          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.

          reply to this | link to this | view in chronology ]

          • identicon
            Anonymous Coward, 8 Feb 2019 @ 1:30pm

            Re: Re: Re: Re: Authentication

            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.

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

            reply to this | link to this | view in chronology ]

            • identicon
              MathFox, 8 Feb 2019 @ 2:31pm

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

              You are right there. The content is different from subscriber or reader lists.

              reply to this | link to this | view in chronology ]

  • icon
    Ninja (profile), 8 Feb 2019 @ 7:13am

    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.

    reply to this | link to this | view in chronology ]

    • identicon
      MathFox, 8 Feb 2019 @ 10:44am

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

      reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 8 Feb 2019 @ 10:45am

      Re:

      considering the Internet goes way beyond the EU.

      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? :)

      reply to this | link to this | view in chronology ]

  • identicon
    Anonymous Coward, 8 Feb 2019 @ 7:26am

    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.

    reply to this | link to this | view in chronology ]

  • icon
    TheResidentSkeptic (profile), 8 Feb 2019 @ 7:29am

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

    reply to this | link to this | view in chronology ]

  • icon
    Get off my cyber-lawn! (profile), 8 Feb 2019 @ 3:13pm

    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.

    reply to this | link to this | view in chronology ]

    • identicon
      Anonymous Coward, 9 Feb 2019 @ 1:57am

      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.

      reply to this | link to this | view in chronology ]


Add Your Comment

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



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown for basic formatting. (HTML is not supported.)
  • Remember name/email/url (set a cookie)

Close

Add A Reply

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



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown for basic formatting. (HTML is not supported.)
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

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

Close

Email This

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