5 ms·

1) It's decrypted and forwarded re-encrypted with the receiver's public key. 2) It's decrypted and re-encrypted with your public key. 3) Same thing that happe

• withinboredom 3y ago
  All emails are basically signed these days via DKIM by your mail service. Each server along the chain should also be signing them too, so your whole path is known and validated. You can validate those keys via DNS. True story, I was an expert witness on a case once where I showed how the other guys were submitting forged emails into evidence -- by using DKIM signatures/hashes. That was probably some of the most fun I've ever had.
  • Infernal 3y ago
    I’ve always wondered about tampering of digital evidence like that, how much it might happen and not be detected, and what the penalty would be if it were.
    • withinboredom 3y ago
      Part of the work was explaining that a print out of an email is just a representation of the email, an actual email contains headers (like a digital stamp) that explain how the email got to where it is (in gmail -- "show original" -- that naming really helped, btw) and without it, you just have a piece of paper with words on it. The equivalent would be printing out the body of a newspaper article without the author or source. You have words, but you can't prove that it came from that newspaper unless someone else can corroborate it.
      • autoexec 3y ago
        Email has been around long enough that it's hard to imagine someone submitting an email as evidence without including full headers. Do you think that it was done intentionally to trick the court or was it just incompetence?
        • macintux 3y ago
          As best as I can recall, Outlook for the Mac doesn’t have any way to see the full headers. I’m skeptical many people know the headers exist.
          • autoexec 3y ago
            Good point! It used to be possible in outlook, but it looks like MS took that option away for years (WTF). Recently (within the last year) they said they brought it back. In Outlook 365 for Mac you should be able to right click on a message and select "View Source" to get the message with the full headers. That's the same way people did it in Outlook for Mac 2011 I agree, most people have no idea headers exist (beyond the short headers), but I expect lawyers and law enforcement to know better. Handling digital evidence is not new and at technology's timescale email is ancient.
          • sigzero 3y ago
            You can but it is clunky. Save the email out as an .eml file and open it in an editor. You see all the headers.
        • unyttigfjelltol 3y ago
          It costs money and attention to insist on full headers. Unless the lawyers think there's something worth digging for, technical details would be omitted from copies just like they are in your email GUI. And, on the other hand, either party can demand the other prove via live witness that the evidence is authentic, reliable and useful. If the witness isnt credible, the document can be excluded.
        • withinboredom 3y ago
    • 0cf8612b2e1e 3y ago
      Knowingly submitting fraudulent evidence is considered a pretty bad idea. Regardless if it is analog or digital.
  • dpifke 3y ago
    DKIM helps for the headers the email provider chooses to sign (such as Subject), but does not attest as to the content of the message.
    • IAmLiterallyAB 3y ago
      Incorrect, DKIM also signs the body of the message.
      • willhackett 3y ago
        Only from the mail server to the receiving mail server.
      • dpifke 3y ago
        You're right and I was wrong. The DKIM signer selects a list of headers (h=) to be signed, but the body is always implicitly included (and thus not listed). I was confused because I thought there needed to be a flag to include it, and had never seen such from Gmail or others. For anyone else that's curious: https://rfc-editor.org/rfc/rfc6376#section-3.7 https://rfc-editor.org/rfc/rfc6376#section-3.7
• asimpletune 3y ago
  Idk about the rest of these but I don’t think 4 would work without ascii armor. Rfc 5322 limits the characters that can be in those headers.
  • reaperman 3y ago
    #4 would be absolutely be "hard" for a lot of reasons, but all those reasons are just "because standards", not technical. Apple/GMail/Office365 together have more than enough influence to establish new standards with modern sensibilities.
• woodruffw 3y ago
  (1) doesn’t preserve sender identity: the receiver is stripping the original signature and/or ciphertext, meaning that B’s forwarding of A’s email to C is not verifiable with A as the original sending identity. Depending on the context, this either doesn’t matter or makes the entire scheme useless. (2) and (3) have similar problems. (4) is a TOFU-ish scheme, meaning that it’s trivial for an adversary on the wire to replace the keys. (5) doesn’t work, full stop. E-mail wasn’t designed with encrypted headers in mind. Trying to shoehorn these things together leads to all kinds of weird misplaced user assumptions around what is signed or not, etc.
  • reaperman 3y ago
    1) When I send an email to someone, why would I care whether they can forward it and prove I wrote what they forwarded? I want to prove I wrote my emails, not theirs. If Apple/GMail/Office365 feel this is important, they can include a signature for the decrypted text -- this could even be togglable. Then when you hit "forward" on an email sent with that toggle enabled it includes the signatures of the earlier senders in the chain for provability of those content blocks. But this isn't how DKIM works and I don't think it really matters. If I'm wrong about it mattering, see above for a quick solution. 2-3) What? Not seeing the problem here? Do you also think encrypted emails need to prevent someone taking a photo of their screen with their phone and sending the photo to someone else? If we can't prevent screenshots and copy/paste of decrypted content, we just shouldn't encrypt anything? What is the logic here? 4) It would also be signed by DKIM and/or the sender's private key, so your proposed MITM attack is not trivial at all. Are you aware of DKIM and PGP signing? You're trying to establish authority with "Email wasn’t designed with encrypted headers in mind [so you can't do it]" but that authority is undermined by not demonstrating understanding of modern email. 5) By the magic of controlling 90% of all end-user email in the western world, a consortium of Apple, Gmail and Office365 can do whatever they goddamned well please.
  • nmilo 3y ago
    Why are you letting perfect be the enemy of the good? Regular email doesn't preserve sender identity when forwarding, and why should that even matter for encrypted mail? Encrypted clients can disable including the original email in a reply, which is totally unnecessary nowadays. And it's okay if headers are unencrypted as long as the client knows it's unsecure. All I'm seeing is a strictly better system than cleartext mail which might have holes around the edges but none that can break the integrity of single-recipient encrypted mail, which is what most people use encrypted email for anyways.
• Groxx 3y ago
  >3) Same thing that happens right now? Two separate emails get sent out each encrypted separately with the receiver's public key. Wouldn't this mean you lose the ability to show all recipients to all recipients? E.g. multiple To or Cc entries seem... probably not possible, since that would imply also sending to them? At that point it isn't "multiple recipients of an email", it's "multiple emails", and that's an only-sometimes-minor difference. I definitely do not know email in enough detail to be sure though.
• jcranmer 3y ago
  > Not sure why any of this would prevent Apple, Gmail, and Office365 from implementing a transparent PGP encryption layer. If just those three entities worked this out, the vast, vast majority of emails in the western world would be encrypted effectively. Just because some emails wouldn't be well-encrypted doesn't change that this would be a huge benefit for privacy. The challenge is key handling, especially the commonality of multidevice access to the mailbox. If you want to do this transparently, the only place you can store the key is... right next to the mailbox, so that anyone with access to the mailbox has access to the key. In other words, you're forced to limit the number of people who can read the message to anyone who has access to the mail server. But there's an easier way to limit the number of possible readers of a message to that set of people--just encrypt all the links involved in sending a message. And that was done about a decade or so ago, and happened pretty transparently. Oh, and there's another problem. Encrypted emails break a lot of email features people like to rely on, such as spam filtering, server-side filters, or server-side search. (Assuming you don't just give up and give the server the keys.) Encrypted email is a solution in search of a problem.
  • reaperman 3y ago
    > If you want to do this transparently, the only place you can store the key is... right next to the mailbox, so that anyone with access to the mailbox has access to the key. If the client can generate a unique public/private key pair for every sender/recipient combination, the key wouldn't need to be stored on any server, just ephemerally transmitted one time over TLS/SSL. But that would have the downside of if you lose all devices with the key, you can no longer read those emails. There's partial solutions for that, like your own collection of public keys could be encrypted with a passkey/passphrase and uploaded to the central server, but then if you lose your passphrase, Gmail still can't help you read past emails. I agree that good key distribution is probably impossible. I'm pretty sure an on-device LLM / statistical model could filter spam pretty darn well though.
• drdaeman 3y ago
  Unless you meant how Protonmail specifically handles it (maybe they do it this way), I think general principles are different in some regards. > 3) Same thing that happens right now? Two separate emails get sent out each encrypted separately I thought the email gets encrypted to multiple recipients (at PGP level), then MUA submits one single email with all those Cc and Bcc addresses. Then the SMTP service sends the same copy (that every recipient can decrypt) to every recipient's individual mail server (one message with per mailhost). Not the way you've described it. I don't think anyone wants to trust SMTP server with their private keys (one single reason I do not use Protonmail). > 4) Separate emails get sent out with the receivers' public keys. I'm afraid this won't work. Mailing lists and encryption are quite incompatible. The whole point of a mailing list is that your client doesn't know or bother to know the recipients - and they can come and go. And if you specify every recipient it's just (3). I'm not aware about any standard on how to implement email lists/archives/newsgroups with encryption (so one joining can read past messages) and forward secrecy (so kicking someone out ensures they can only read what they have already seen). > 5a) Everything. Problem with existing email infrastructure is that MTAs and MDAs do a lot of transformations on the headers part of "everything". So just saying "everything" isn't exactly informative. I think the best approach is to send a full MIME-encrypted message as an attachment in a minimal envelope (so just From/To/Subject). But then there's the infamous SPAM problem - and I'd really wish it would've worked, but sadly filtering solely based on sender-receiver pairs doesn't work in reality (or I wouldn't have to maintain and train rspamd on my servers).
  • reaperman 3y ago
    I was proposing that as a back of the napkin sketch for how Apple+Gmail+Office365 could implement it. But this description of ProtonMail is hugely illuminating.
    • drdaeman 3y ago
      This wasn't a description of Protonmail - I don't have much experience with them specifically and they may do some things differently, but of one's casual email service, like how people use PGP with existing mail systems. I also do not claim that description to be 100% accurate - it's been a while since I've used PGP with email in practice, so I might misremember something. But to best of my awareness, this is how things are done today. In my opinion, the main three problems with PGP today are: 1) lack of good no-frills "just works"-type tools; 2) issue with email metadata (at the very least, to/from addresses) being impossible to encrypt by design; and 3) abundance of haters (and they have a lot of right arguments, although many just boil down to the tooling issue and how it's easy to shoot everyone's legs with the current tools) who claim PGP should be buried (all together with email) - which is not exactly wrong.
• AnonC 3y ago
  In 4), what you describe about sending email to a mailing list is not clear to me. Are you saying that the mailing list will have a public key that’s used for encryption (by the original sender) and that the mailing list software will decrypt and re-encrypt with the public key of each member when sending the emails? If yes, then if some members don’t support receiving encrypted emails, those would certainly go unencrypted. In other words, there’s no guarantee (except in small and close groups) for this to work as intended.
• Sebb767 3y ago
  > Same thing that happens right now? Two separate emails get sent out each encrypted separately with the receiver's public key. Minor correction, but this is not true. The mail itself is encrypted symmetrically and only the key is encrypted with the receivers public key (this is true for all cases). In case of multiple receivers, the key is attached multiple times, encrypted with the PK of each receiver.