3 ms·

This is entirely the wrong lesson to take from this. Why are we still using a plaintext protocol in this day and age? Why can we not get an E2EE addition to the

This is entirely the wrong lesson to take from this. Why are we still using a plaintext protocol in this day and age? Why can we not get an E2EE addition to the email protocol with full backwards compatibility? Yes, I understand that it would be imperfect since inevitably not all servers would support it thus forcing additional understanding and decisions on the end user. No, I don't care that a user other than myself might leak my messages in plaintext. Perfectionism in this regard only serves to further shoot us in the foot. Yes, I understand that key distribution is a difficult problem but then that's the case no matter the protocol. Other protocols have solutions that work reasonably well at this point. There's no justification for the current status quo. Alternatively I'd be fine using matrix for all my PII related needs (healthcare, government, subscription services, etc, etc) but somehow I don't see that happening any time soon.

laughing_man 4mo ago
Getting from here to there is going to be tough, but I agree 100%. Not only should email be E2EE, but it should include a certificate scheme such that you know the person purporting to be the sender is actually the sender.
- fc417fc802 4mo ago
  Given that the cryptography would necessarily be asymmetric verifying the sender on a TOFU basis seems like a trivial addition (just sign something). I doubt you can do better than TOFU though unless you tie it to an external ID system (corporate or government or etc issued hardware tokens or similar).
- wvh 4mo ago
  PGP had the right idea, but the system is too hard for the average person. With "system" I refer to building a web (or multiple!) of trust, based on parameters that you decide upon.
fsflover 4mo ago
How about the metadata? Perhaps if you mean something like self-hosted Matrix, then I agree.
nottorp 4mo ago
For large organization data the keys would need to be stored within the organization, not with one particular user as in the case of your personal PII needs. And then you'd still need to worry about digital sovereignity for the keys.
- fc417fc802 4mo ago
  I don't follow. Are you saying that BigCorp would demand key escrow? They already deploy custom email solutions today so I don't see the issue.
  - nottorp 4mo ago
    I am saying you can't keep the keys just on a stick in the employee's pocket since multiple people need to have access to the data. And if those keys are stored by a company subject to US jurisdiction, we're back to the same problem.
    - fc417fc802 4mo ago
      Well yes, if you hand your keys over that is indeed a problem. Of course handing your keys over to the provider rather defeats the purpose of E2EE so hopefully no one is doing that. Key escrow is the usual solution to an employer needing access to employee materials.
      - nottorp 4mo ago
        > Key escrow is the usual solution Yes, and you move the problem to "is the entity/process/whatever handling key escrow under US jurisdiction"?
        fc417fc802 4mo ago
        Yes, obviously, but key (/account/identity/etc) management is typically a much narrower and well defined problem to solve and in many cases it will already have been solved (centralized management of user accounts, employee ID cards that contain physical tokens, and other such things).
vrganj 4mo ago
For a public institution you want some sort of accountability / auditing mechanism, so you can't just do E2EE encryption between users. Otherwise, a public servant could do sketchy stuff behind the public's back with no paper trace. What you don't want is hostile foreign capitalists leaking your data to their local authoritarians. They are not your public and shouldn't have the data in the first place.

laughing_man 4mo ago

Getting from here to there is going to be tough, but I agree 100%. Not only should email be E2EE, but it should include a certificate scheme such that you know the person purporting to be the sender is actually the sender.

fc417fc802 4mo ago
Given that the cryptography would necessarily be asymmetric verifying the sender on a TOFU basis seems like a trivial addition (just sign something). I doubt you can do better than TOFU though unless you tie it to an external ID system (corporate or government or etc issued hardware tokens or similar).
wvh 4mo ago
PGP had the right idea, but the system is too hard for the average person. With "system" I refer to building a web (or multiple!) of trust, based on parameters that you decide upon.

fsflover 4mo ago

How about the metadata? Perhaps if you mean something like self-hosted Matrix, then I agree.

nottorp 4mo ago

For large organization data the keys would need to be stored within the organization, not with one particular user as in the case of your personal PII needs. And then you'd still need to worry about digital sovereignity for the keys.

fc417fc802 4mo ago
I don't follow. Are you saying that BigCorp would demand key escrow? They already deploy custom email solutions today so I don't see the issue.
- nottorp 4mo ago
  I am saying you can't keep the keys just on a stick in the employee's pocket since multiple people need to have access to the data. And if those keys are stored by a company subject to US jurisdiction, we're back to the same problem.
  - fc417fc802 4mo ago
    Well yes, if you hand your keys over that is indeed a problem. Of course handing your keys over to the provider rather defeats the purpose of E2EE so hopefully no one is doing that. Key escrow is the usual solution to an employer needing access to employee materials.
    - nottorp 4mo ago
      > Key escrow is the usual solution Yes, and you move the problem to "is the entity/process/whatever handling key escrow under US jurisdiction"?
      - fc417fc802 4mo ago
        Yes, obviously, but key (/account/identity/etc) management is typically a much narrower and well defined problem to solve and in many cases it will already have been solved (centralized management of user accounts, employee ID cards that contain physical tokens, and other such things).

vrganj 4mo ago

For a public institution you want some sort of accountability / auditing mechanism, so you can't just do E2EE encryption between users. Otherwise, a public servant could do sketchy stuff behind the public's back with no paper trace. What you don't want is hostile foreign capitalists leaking your data to their local authoritarians. They are not your public and shouldn't have the data in the first place.