Conversation

Notices

1. Embed this notice
   Taylor R Campbell (riastradh@mastodon.sdf.org)'s status on Monday, 29-Jan-2024 21:37:24 JST Taylor R Campbell

   Do you run a mail server, or own a domain example.com that you send mail from?

   PSA about the Coming DKIMpocalypse on Thursday when Google and Yahoo tighten mail rules:

   https://support.google.com/a/answer/81126?hl=en
   https://senders.yahooinc.com/best-practices/

   1/3. The mail server must sign outgoing mail with DKIM. You generate a key pair called “foo” (e.g., with opendkim-genkey), configure your mail server to use it, and publish the public key in the DNS like:

   foo._domainkey.example.com. IN TXT (
   "v=DKIM1; k=rsa; "
   "p=..."
   )

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Monday, 29-Jan-2024 21:43:23 JST Rich Felker

     in reply to

     @riastradh Why just publish old ones retroactively when you could X-DKIM-Private-Key: in each mail? 😈

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Taylor R Campbell (riastradh@mastodon.sdf.org)'s status on Monday, 29-Jan-2024 21:43:24 JST Taylor R Campbell

     in reply to

     How can you use this to shoot yourself in the foot and make your mail undeliverable to Goohoo! users?

     - skip DKIM signature
     - exclude your IP from SPF policy
     - send mail where “From” doesn't match sender or DKIM domain—e.g., write to a mailing list that forwards your message—and set “p=quarantine” or “p=reject” in DMARC

     You can also inundate yourself with extra mail from your recipients by adding “rua=mailto:postmaster@example.com”, because who doesn't thirst for more mail?

   • Embed this notice
     Taylor R Campbell (riastradh@mastodon.sdf.org)'s status on Monday, 29-Jan-2024 21:43:24 JST Taylor R Campbell

     in reply to

     Bonus: DKIM creates a leak incentive because the mail server cryptographically attests to every message you write, in signatures that anyone in the world can verify—even on private messages not meant for public consumption.

     So you might want to rotate your DKIM keys and publish the old ones periodically:

     https://blog.cryptographyengineering.com/2020/11/16/ok-google-please-publish-your-dkim-secret-keys/

   • Embed this notice
     Taylor R Campbell (riastradh@mastodon.sdf.org)'s status on Monday, 29-Jan-2024 21:43:25 JST Taylor R Campbell

     in reply to

     3/3. The domain of your ”From: ...@example.com” header fields must have a DMARC policy in the DNS, like:

     _dmarc.example.com. IN TXT "v=DMARC1; p=none"

     And as a reward for all your hard work to implement this rigmarole, this will do absolutely nothing to reduce anyone's spam!

     At best, you can tighten the SPF and DMARC policies to restrict phishing attempts made using your domain, but there are foot-guns…

   • Embed this notice
     Taylor R Campbell (riastradh@mastodon.sdf.org)'s status on Monday, 29-Jan-2024 21:43:26 JST Taylor R Campbell

     in reply to

     2/3. The domain of the envelope sender you use must have SPF policy in the DNS that doesn't exclude your mail server's IP address, like:

     example.com. IN TXT "v=spf1 ?all"

     If your mail server is at, say, 198.51.100.42, you might improve odds of delivery by including it explicitly:

     example.com. IN TXT "v=spf1 ip4:198.51.100.42 ?all"

     (This one isn't new—you probably already had to do this a long time ago.)

   • Embed this notice
     Ryan Castellucci :nonbinary_flag: (ryanc@infosec.exchange)'s status on Thursday, 01-Feb-2024 18:03:23 JST Ryan Castellucci :nonbinary_flag:

     in reply to

     • Rich Felker

     @dalias @riastradh This historically allowed arbitrary impersonation of your domain because SPF is ignored if DMARC is enabled and DKIM is valid. You could encrypt it with a key that's mostly zero bits though.

     I wrote up my tooling for publishing keys:

     https://rya.nc/dkim-privates.html

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Thursday, 01-Feb-2024 18:03:24 JST Rich Felker

     in reply to

     @riastradh Thinking more about it, X-DKIM-Private-Key header is actually *needed* to fix the non-repudiation leak DKIM entails

     Retroactively publishing keys still admits a non-repudiation attack by having (hashes of) emails notarized before the retroactive key publishing happens, possibly even doing so on receiving SMTP endpoint and prepending notary receipt to headers.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 21-Feb-2024 20:28:48 JST Rich Felker

     in reply to

     • Death by Lambda

     @xdydx @riastradh This 👆 is the ultimate asshole position on privacy.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Death by Lambda (xdydx@mastodon.social)'s status on Wednesday, 21-Feb-2024 20:28:49 JST Death by Lambda

     in reply to

     • Rich Felker

     @dalias @riastradh

     I think the simpler solution is not to write emails whose leakage could be embarrassing

   • Embed this notice
     Death by Lambda (xdydx@mastodon.social)'s status on Wednesday, 21-Feb-2024 20:28:50 JST Death by Lambda

     in reply to

     • Rich Felker

     @dalias
     Cheers. In context of your other reply this makes sense and makes @riastradh post much clearer!

     So effectively there is a school of thought that says for #dkim to be both effective and not a threat you would need to be able to
     • generate a private key per email
     • insert it into the header
     • sign the entire message
     • publish the dkim record during transit
     • profit...

     #somePeopleJustWantToWatchTheWorldBurn

   • Embed this notice
     Taylor R Campbell (riastradh@mastodon.sdf.org)'s status on Wednesday, 21-Feb-2024 20:28:51 JST Taylor R Campbell

     in reply to

     • Rich Felker

     @dalias Caveat: Gotta remember to make the signature the cover X-DKIM-Private-Key header field! Otherwise the leaker could just strip it off.

     (Also, I suspect that if a lot of senders started doing this, Google might not find the idea as amusing as you and I do!)

   • Embed this notice
     Death by Lambda (xdydx@mastodon.social)'s status on Wednesday, 21-Feb-2024 20:28:51 JST Death by Lambda

     in reply to

     • Rich Felker

     @riastradh @dalias
     I'm going to ask you to please explain this one as well!

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 21-Feb-2024 20:28:51 JST Rich Felker

     in reply to

     • Death by Lambda

     @xdydx @riastradh Including the private key in the email itself ensures the signed email itself proves there was never a time window during which the private key was not already compromised and during which anyone could have forged the contents.

   • Embed this notice
     Rich Felker (dalias@hachyderm.io)'s status on Wednesday, 21-Feb-2024 20:29:40 JST Rich Felker

     in reply to

     • Death by Lambda

     @xdydx @riastradh The simpler solution would be to stop trying to force people who don't want DKIM to use it.

     In the absence of that, malicious compliance is the only option. In that case you don't care if it's effective because you didn't ask for it. You just want to check the box.

     Haelwenn /элвэн/ :triskell: likes this.