Subject: [hrpc] Internet Architecture Board warns Australian encryption-busting laws could fragment the internet

From: Mark Perkins <[email-masked]>
Date: Sat, 3 Nov 2018 21:32:23 +0000 (UTC)

Not sure if people had seen this news
Internet Architecture Board warns Australian encryption-busting laws could fragment the internet
https://www.zdnet.com/article/internet-architecture-board-warns-australian-encryption-busting-laws-could-fragment-the-internet/

Mark P.

---

From: [email-masked]
Date: Sat, 3 Nov 2018 22:20:41 -0400

And Denmark will require "email encryption" as of 1/1/2019 or in
European format 1/1/2019.

  https://litmus.com/blog/beyond-gdpr-denmark-makes-email-encryption-mandatory

This has all become a massive buzzword cargo cult with
legislators...they can manage to send/receive stuff on their phone so
surely they are expert in how it all works.

Apparently Denmark's legislation has chosen to omit the details of
what they mean by encryption of emails (end to end? transport? other?)

But the article linked below is your usual fantasy legislation.

Why not just make cancer illegal? Millions suffer and die from cancer
and it costs many billions to treat, we need a law!

On November 3, 2018 at 21:32 marknoumea=[email-masked] (Mark Perkins) wrote:
 > https://www.zdnet.com/article/
 > internet-architecture-board-warns-australian-encryption-busting-laws-could-fragment-the-internet
 > /
 > 
 > Mark P.
 > _______________________________________________
 > hrpc mailing list
 > [email-masked]
 > https://www.irtf.org/mailman/listinfo/hrpc

-- 
        -Barry Shein

Software Tool & Die    | [email-masked]             | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD       | 800-THE-WRLD
The World: Since 1989  | A Public Information Utility | *oo*

---

From: Mark Perkins <[email-masked]>
Date: Sun, 4 Nov 2018 05:27:22 +0000 (UTC)

BarryWith a bit of digging into the announcement (with help from Google Translate), it sems that Denmark is making existing recommendations obligatory. The existing recommendations seem to be:
"What type should we use?

As mentioned in the section on rights and obligations above, it is always the data controller who, based on his risk assessment, must assess the level of security that is appropriate. Accordingly, according to the Data Inspectorate, there would be types of processing where encryption on the transport layer is appropriate and there will be types of treatment where - due to the high risk of the data subjects - the more secure end-to-end encryption will be appropriate. This could be the case, for example, if a data controller, such as an insurance company, has to send health information about a large number of registrants to a data broker for sending letters. In that case, on the basis of a risk assessment, the data controller may decide that end-to-end encryption will be an appropriate security measure. Due to ongoing collaboration with the data processor, the two parties have exchanged S / MIME certificates, so they can send e-mails back and forth to each other, which is end-to-end encrypted."
<https://www.datatilsynet.dk/emner/persondatasikkerhed/transmission-af-personoplysninger-via-e-mail/>

Mark P.

    On Sunday, November 4, 2018, 1:32:18 PM GMT+11, <[email-masked]> wrote:  

-- 
        -Barry Shein

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 4 Nov 2018 14:49:30 +0100 (CET)

> Il 4 novembre 2018 alle 3.20 [email-masked] ha scritto:
> 
> 
> 

It is already "required if appriopriate" by the GDPR and would also be explicitly required throughout the EU by several versions of/amendments to the upcoming (maybe) ePrivacy Regulation. Then, of course, no one still knows how to implement proper end-to-end encryption for email in general, as there are too many competing standards for certain things and no standard for others, and it is unclear how you could even get the average user to create and manage their encryption keys without letting the application/service provider do it for them, which turns end-to-end encryption into "managed" end-to-end encryption a la Whatsapp, which means that the content of the message is encrypted for everyone except the recipient... and Facebook. (Though with email you can at least choose your client/service provider, something you can't do with the instant messaging siloses.)
But, again, this would be a good challenge for the Internet's technical community.
Ciao
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: [email-masked]
Date: Mon, 5 Nov 2018 00:05:43 -0500

A quick and very informal statistical glance at the ratio of
successful vs unsuccessful SMTP TLS connections at this ISP
(TheWorld.com) showed about 10% success.

Granted that might be skewed by the number of totally insincere
attempts by spammers and similar.

But sometimes things look different from the trenches.

I'm a little disturbed that the soon to be mandatory Danish
recommendations specifically call for S/MIME certificates. There's
nothing wrong with them -- well there are problems, everything has
problems, e.g., EFAIL -- but there are other alternatives. I'll hope
one can read that as "...or equivalent industry standard encryption
methods".

Another problem which leaps to mind is that email delivery is
inherently store-and-forward which means a message might travel
through various jurisdictions before final delivery.

The bigger point is the sentiments might be laudable but the practical
issues loom nonetheless.

-- 
        -Barry Shein

---

From: Mallory Knodel <[email-masked]>
Date: Mon, 5 Nov 2018 12:20:18 +0700

> But, again, this would be a good challenge for the Internet's technical community.

Hi,

There is LEAP (Leap Encryption Access Project) that is trying to solve
the issue of managed e2e encryption that doesn't disclose information to
the server.

https://leap.se

I particularly like their analysis of The Hard Problems. But whether or
not this project and code will reach all email users remains to be seen.

-Mallory

-- 
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780