Re: [openpgp] Remove email metadata by encrypting headers using the published DKIM key

Hi Kai,

interesting idea.

I'd be concerned about the use of the same key for both signing and
encryption.

I guess the changes your idea brings are big enough to warrant a
separate DKIM-like mechanism, maybe a "DomainKeys Encrypted Mail" (DKEM)
that works about the same as DKIM.

Compared to DKIM, though, the recipient server cannot process mails when
the key is not available (or a wrong key is used) which seems like a
rather big obstacle.

Also, I guess, using HTTPS is considered to be more popular than using
DNSSEC for distributing such information. So you could envision
something like MTA-STS.

Best,
  Tobi

On Thu, 2022-06-23 at 10:31 +0200, Kai Engert wrote:
> I'd like to drop the following idea about reducing some metadata from 
> emails.
> 
> While the OpenPGP list isn't the perfect fit for this suggestion, I'm 
> guessing that many of you might have an opinion on this idea, given
> that 
> PGP is related to privacy and email. Please suggest a better place to 
> discuss this, if there is one.
> 
> While this idea might be applicable to additional email headers, I'll 
> start by talking about the recipient headers TO and CC.
> 
> Today, emails leak information about the sender and the recipients of
> an 
> email to everyone along the route.
> 
> If a domain has published an RSA key for DKIM signatures on DNS (and 
> signals on DNS that it opts in to the encryption mechanism described 
> here), then agents that send email to that domain could encrypt the
> list 
> of recipients.
> 
> For example, if the intended recipient is someone@example.com, the
> agent 
> could encrypt "someone" and encode it as base64. The software on the 
> recipient server could then use the DKIM key to decrypt the message.
> 
> Simply replacing the addresses doesn't work for emails with
> recipients 
> on more than one domain, because the server on each recipient domain 
> must be able to decrypt the list of recipients.
> 
> So maybe alice@business.example.com could be replaced by 
> enc-recip-1@business.example.com, and bob@ngo.example.com could be 
> replaced by enc-recip-2@ngo.example.com, and an email header for each 
> combination of {recipient, destination-domain} could be added:
> 
> X-enc-recip-which: (replacement-identifier) 
> (encrypted-base64-encoded-mailbox-name) (domain key that can decrypt 
> this cipher)
> 
> Example:
> 
> X-enc-recip-to: enc-recip-1 ZWNpbGEK business.example.com
> X-enc-recip-to: enc-recip-2 b2JiCg== business.example.com
> X-enc-recip-cc: enc-recip-1 RUNJTEEK ngo.example.com
> X-enc-recip-cc: enc-recip-2 T0JCCg== ngo.example.com
> 
> Possibly also:
> 
> X-enc-from: enc-recip-0 Y2hhcmxpZQo= business.example.com
> X-enc-from: enc-recip-0 Q0hBUkxJRQo= ngo.example.com
> 
> Some domains want to use separate servers for sending emails and 
> receiving emails, and they might prefer to store the DKIM sending key
> on 
> the servers for outgoing email, only. That would require that
> optionally 
> a separate key could be published by the domain for receiving
> encrypted 
> headers. Because some sort of signaling is required that allows a
> server 
> to opt in to receive encrypted headers, it might be better to not
> reuse 
> the DKIM keys, but rather define a separate DNS record for publishing
> an 
> encryption key for receiving such headers.
> 
> Above this paragraph is the generic description of the new idea that 
> could (maybe) reduce the amount of meta data in emails.
> 
> Below this line is a rough idea for a potential application. I'm not 
> claiming the idea is practical, I'm just offering it as an example
> for 
> how the metadata reduction could be beneficial.
> 
> Let's say uncensored@example.com is an email robot, that offers the 
> retrieval of documents from wikipedia.org and archive.org, intended
> for 
> users like Garry, who lives in Censorland, which censors access to
> those 
> sites.
> 
> Garry sends email to uncensored@example.com, asking for the wikipedia 
> article on Special-Peace-Collaboration.
> 
> If the email address uncensored@example.com can be seen in the email
> in 
> the clear, then the admins of Censorland can easily block it as
> undesired.
> 
> However, if example.com is a large email provider, encrypting the
> true 
> recipient mailbox is a domain fronting approach to make blocking the 
> mailbox difficult.
> 
> The email that Garry sends could be encrypted using OpenPGP, to hide 
> which article Garry is requesting. Garry could also include their
> public 
> key, allowing the email robot to encrypt the article that is sent to 
> Garry by email in response.
> 
> (When sending the response to Garry, in addition to encrypting the 
> article, the email should also use a fake sender address, to not
> reveal 
> the true origin of the email to the Censorland email server
> operators.)
> 
> Sent in the hope these ideas make some sense and could be useful.
> 
> Kai
> 
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp