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

[Stephen Farrell <[e-mail]>]

Hiya,

On 23/06/2022 09:31, 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.

I think you're correct in the above (that this isn't the best
list for this). I'd suggest [e-mail] would be a
good fit, perhaps after an initial I-D has been crafted. (To
be clear: I'm not objecting to initial discussion here just
noting that this list isn't a place where we ought aim to
dispatch or dispose of the idea.)

Cheers,
S.

PS: Personally, I'd share some of the concerns mcr expressed
about the idea being practical - one additional issue would
be that, for this to be anywhere near reliable, you'd need a
marker on the public key RR in the DNS to signal the decrypt
capability, which means changes to DKIM public keys, which I
think means it'd be near as easy to publish new RRs for the
new purpose, with new keys. (Given that domains generally do
not ever change their DKIM public keys;-)

> 
> 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 [e-mail], 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 [e-mail] could be replaced by 
> [e-mail], and [e-mail] could be 
> replaced by [e-mail], 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 [e-mail] 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 [e-mail], asking for the wikipedia 
> article on Special-Peace-Collaboration.
> 
> If the email address [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/openpgp