8 ms·
DKIM: Show Your Privates
- m0zg 6y agoFor a practical example, see https://github.com/robertdavidgraham/hunter-dkim https://github.com/robertdavidgraham/hunter-dkim
- 0xy 6y agoThe fact you're getting downvoted lays bare the bias of HN. Cryptographic proofs (math) clash against ideology, and ideology wins.
- Thorrez 6y agoIt's funny how the top comment in this thread is someone asking how leaking your public key would ever be useful. And a comment giving a very concrete example of how it's useful is at the bottom.
- dane-pgp 6y agoMaybe the average HN user would rather keep cryptography in the cryptography discussions and ideology in the ideology discussions. I don't necessarily agree with that, but it's not evidence of "bias".
- Thorrez 6y agoIt would have been nice if the original post mentioned this.
- dddddaviddddd 6y agoI can imagine why the author could maybe want plausible deniability against potentially leaked or forged emails, but I definitely see DKIM and non-repudiation a feature. I suppose the caveat is that if DKIM private keys were stolen, fraudulent emails could be convincingly generated, but this isn't a normal concern for users of the big hosted webmail services.
- amingilani 6y agoOne valid use case of non-repudiation that I can think of is the Poor Man's Copyright[0], where you email yourself your creative and have a timestamped record of when it existing. [0]: https://en.wikipedia.org/wiki/Poor_man%27s_copyright https://en.wikipedia.org/wiki/Poor_man%27s_copyright
- sebmellen 6y agoPoor man's copyright is unfortunately quite tenuous and usually unenforceable. At my start-up we've built an analogous system which instead uses a public blockchain for notarization (as dirty as that word has become). https://assembl.net https://assembl.net or https://app.assembl.net https://app.assembl.net if you'd like to try timestamping right away. Non-repudiation here is useful, but the timestamping is the more important piece.
- markdown 6y agoOT, but if you're going to use a miss-spelled word, by not get one with an available .com?
- sebmellen 6y agoEh, fair question. Assembl is a pretty sought after name which we have the trademark on. I came up with the name after thinking it was necessary to "assemble" teams of scientists for collaborative research. I liked the name "Assembl" as it's the root for "assemble", "assembling", "assembly", etc. - https://assembl.org https://assembl.org and - https://assembl.co https://assembl.co are both infringers, but we haven't decided to go after them. The owner of https://assembl.com https://assembl.com cannot be compelled to sell it, but can't sell it to anyone but us. For now, the focus is mainly on providing value to our userbase, as we grow these challenges are surmountable.
- ttul 6y agoOr you could just use S/MIME. DKIM wasn’t designed for the purpose the author describes. But S/MIME works great for this purpose.
- fogihujy 6y agoAlas, S/MIME is relatively complicated and can't really be used by the general public without re-teaching everyone how email work (lost keys will be a support nightmare). But yeah, S/MIME signing is incredibly useful for the specific purpose the article suggests.
- _-___________-_ 6y agoIt's not really non-repudiation if the keys are not controlled by the author of the email. In the case of Gmail, Google is signing the outgoing mail on your behalf. Anyone at Google, and anyone with access (whether obtained legitimately or not) to your Gmail account, could have written the email.
- bradleybuda 6y agoThere are degrees of non-repudiation. In a court of law, you may be right - there is reasonable doubt as to authorship. But when a public figure's emails leak to the New York Times, the standard might be a little lower.
- fortenforge 6y agoOf course, this scheme only works if the leaked emails are published at least 10 days after the day the email was sent. If we build non-repudiation into the DKIM framework itself we can do better, as this paper does. https://www.mit.edu/~specter/assets/pdf/sec21KF.pdf https://www.mit.edu/~specter/assets/pdf/sec21KF.pdf
- walrus01 6y agoTrying to retrofit "we guarantee this really came from this person on this date" features onto server-to-server SMTP transport is a losing game in my opinion. I've been running smtpd on the Internet since 1996, for ISP purposes. DKIM is all fine and good, and a beneficial thing as part of a multi pronged anti spam approach, and for the general health of the Internet. But it's not meant to be used with rotating a key every day. My worry is that some hacked up setup like this will provide people with a sense of false confidence that shouldn't exist. Email is still like a postcard, not a sealed envelope. I would consider it a very poor idea to have a set of automatic scripts messing around with the MX records or DKIM records on the domain zonefiles on my set of authoritative-only nameservers. Those things aren't meant to change often. All of the considerations involved in setting up and running your own smtpd in a highly reliable manner in the year 2020 (not just pointing your MX records to office365 or gsuite and calling it a day)... Yes you should run DKIM. You should pay attention to stuff like DMARC, SPF, your IP space reputation, proper configuration of your smtpd, your own smtpd's configuration to discard incoming stuff based on RBLs and spamassassin, as I have my postfix system set up to do. But ultimately server to server SMTP in the year 2020 is a hack job piled on top of a hack job. There is no need to start doing things that require you to set very low TTLs on your domain zonefiles and then blindly trust that every caching DNS resolver out there on the internet will respect that (breaking news: they won't! it will break mail delivery in new and amazing ways!). If you want a proper cryptographically secured end to end communication method, it's not anything that speaks SMTP. Go use Signal to chat or something.
- tialaramex 6y agoThe "hack job piled on top of a hack job" argument doesn't amount to as much as you seem to think. This weekend Rescorla et al published the Internet Draft of Compact TLS. cTLS is (intended to be) exactly the same functionally as TLS 1.3. Except that the "spelling" is er, compact. For example, your "real" TLS 1.3 connections have a connection ID in them. That seems sane right? Well, the content of that ID is a bunch of random gibberish, echoed back by the server. It doesn't do anything useful at all, it isn't identifying anything, it's just some random bytes in a system that already has dozens of random bytes that are there on purpose anyway. So why is it there? It's there because in TLS 1.2 that connection ID field was used to resume previous sessions and so lots of middleboxes will just assume everything must be fine so long as you fill out the connection ID and then the remote server appears to continue the same session. Such middleboxes can't snoop because they don't know enough about this hypothetical session which never happened, but since they are just security theatre anyway it doesn't matter, your connection succeeds. This makes TLS 1.3 actually work, developing such workarounds by tweaking the "spelling" took about a year. But the security proofs are the same for compact TLS and the "real" TLS 1.3 shipped in your browser. It's just that the real thing is "a hack job piled on top of a hack job" because that works. Mathematics doesn't care how you spell it, if you've come up with an incredibly convoluted way to do something apparently easy, but the math checks out anyway, it still works.
- chocojazz 6y agoIs anyone else incredibly put off by the title of this article? It may be a pun, but an extremely insensitive one that just comes off as callous, especially given that we're in a period of time where very real repercussions of a careless attitude towards cutting-edge technology are increasingly coming to light (e.g. DeepFake being used maliciously). The article's fine; seeing this title on my news feed just made me feel sad.
- ponker 6y agoAgree - the title grabs the wrong kind of attention. It's sad to see the deeply technical realm co-opted by the same kind of clickbait attention-seeking that powers celebrities/social media/etc.
- curben 6y ago> ...email providers to try deploying a key management strategy similar to the one I’ve described in this post. Assuming author meant key rotation, Protonmail[1] offers automatic key rotation by using CNAME that alias to DKIM TXT which is rotated once in a while. [1]: https://protonmail.com/support/knowledge-base/anti-spoofing/ https://protonmail.com/support/knowledge-base/anti-spoofing/
- ryan-c 6y agoAutomatic DKIM key rotation is common, I'm talking about publishing private keys.
- AnonHP 6y agoCan someone explain this entire article in simpler terms? I read the other comments here, but they weren’t helpful for me. I understand technology, I understand the concepts of public key cryptography, I think I understand what DKIM is used for (verification that the specific domain’s server did send a specific email because it’s signed, which can be verified by the receiving party using the key published in the DNS record)...yet I found this article to be terse (along with the short Twitter thread initiated by Matthew Green). Is the author just building plausible deniability by publishing the keys? Would this even truly stand up as believable for any scenario? And why is Matthew Green suggesting this? Thank you very much!
- Thorrez 6y ago>Is the author just building plausible deniability by publishing the keys? Yes. >Would this even truly stand up as believable for any scenario? The post says this will most likely only work in a leak situation rather than a legal dispute. An example of where this might be useful: You send an email to a friend revealing something sensitive about yourself. A hacker hacks your friend's email and leaks it out. Without plausible deniability, everyone can verify cryptographically that you did in fact say that sensitive stuff (assuming your own email didn't get hacked). With this technique, people cannot verify whether or not you said it, the email might be a fraud and so people are less likely to believe the sensitive thing about you.
- outsomnia 6y ago> With this technique, people cannot verify whether or not you said it, the email might be a fraud and so people are less likely to believe the sensitive thing about you. If the recipient can prove he had the signed email before the signing private key was made public, eg, by contemporary third party notarization, the keys becoming public later don't help with disclaiming it at all.
- some_furry 6y agoYes, that's the point though: To make DKIM not serve as a non-repudiation mechanism. It forces actors to go through other notarization steps instead of relying on DKIM.