I think this is a shameful argument. Non-repudiation over time is a truly powerful property of DKIM'd email for a great many uses outside of blackmail. Calling for the ability to remove it during the years 2016-2020 in order to "protect politicians from blackmail" is not only of deeply questionable value but of suspect motivation. Who is the author interested in protecting?
Ok Google: please publish your DKIM secret keys
81–90 of 492 posts
Re: Ok Google: please publish your DKIM secret keys
#82In messaging cryptography, non-repudiability has for almost 2 decades been considered a vulnerability, not a feature. The OTR protocol[1] takes the step of publishing its used MAC keys --- it releases private key material! --- to ensure that random people can forge messages once participants have authenticated them. Signal came up with a novel deniable AKE[1] that is one of the more famous parts of the protocol; by design, you can forge a Signal conversation from someone's private key even if you've never talked to them before.†
When you think about it in the abstract, it's easy to understand what's going on, even if you don't take the time to read the OTR paper. Once counterparties have authenticated each others messages, authentication has served its purpose. To allow a stranger to authenticate a messages is to concede information to them, and avoiding concessions is the point of messaging cryptography.
If you believe non-repudiable messages are necessary for public policy, it's hard for me to understand how you'd support the rest of secure messaging. Most secure messengers also have "disappearing messages", which have an even more powerful impact on the public's ability to read your (or some disfavored other's) messages. In fact, keeping the public from reading stuff is... kind of the obvious point?
Maybe it's just email, and the belief that email should not just be insecure, but be deliberately insecure? But, you all get how weird it is for me to read that after getting yelled at for writing a blog post about avoiding secure email, right? 547 comments[3]! Many of them very angry!
[1]: https://otr.cypherpunks.ca/otr-wpes.pdf
[2]: https://signal.org/blog/simplifying-otr-deniability/
[3]: https://news.ycombinator.com/item?id=22368888
† I'm always looking for this triple-DH blog post and never able to find it, because it doesn't contai the word "triple", and it never occurs to me to search for "deniable", only "repudiability" (which also doesn't occur in the blog post) so I guess I can thank this thread for fixing my bookmark.
Re: Ok Google: please publish your DKIM secret keys
#83I think this is a shameful argument. Non-repudiation over time is a truly powerful property of DKIM'd email for a great many uses outside of blackmail. Calling for the ability to remove it during the years 2016-2020 in order to "protect politicians from blackmail" is not only of deeply questionable value but of suspect motivation. Who is the author interested in protecting?
> Non-repudiation over time is a truly powerful property of DKIM'd email for a great many uses outside of blackmail. Exactly. If one enters into an contract using an e-mail, then DKIM can be used as a proof to the court of law that the contract was accepted by both sides.
It would make a good TV drama plot, but courts don't work this way in real life. If that were the case, courts wouldn't be able to enforce contracts with wet signatures (which are straightforward to forge), or verbal contracts (which are valid contracts and regularly enforced).
In practice, you don't need to check DKIM in order to use an email as evidence of a contract, because the courts would more likely just use the many other threats and tools at their disposal to ensure that the email is not fabricated.
This is why, even though most contracts are not executed in a cryptographically secure manner, most contract disputes that land before the courts hinge on matters like breach of contract ("we agree on the original terms, but disagree on whether our actions upheld them") or disputes over the intended vs. actual meaning of the contract ("we agree on the text we both signed to, but disagree on the correct interpretation of that text").
Disputes over whether the text of the executed contract is authentic are rare in real life.
Re: Ok Google: please publish your DKIM secret keys
#84So the author's central thesis essentially seems to boil down to that leaked emails were able to be cryptographically verified, because of DKIM and so we should prevent that so people can't use email to blackmail politicians? Ultimately I prefer the more information that we can get on politicians available. It seems to me that especially when an elected official has something they don't want others to know about that…
I don't think Matthew Green is arguing against transparency. What he's observing is that non-repudiation is an unintentional byproduct of DKIM's design. Because it's a byproduct, DKIM's users have made implementation decisions that make it susceptible to weaknesses in the unintentional non-repudiation property.
By 2030, a motivated nation state will probably have the ability to crack the 2048-bit RSA keys that Google is currently using for DKIM. Do you really want someone in 2031 to be able to contrive fake signatures for the emails of politicians in 2021?
Re: Ok Google: please publish your DKIM secret keys
#85What if someone realizes that Google uses a broken cryptographically secure pseudorandom number generator (CSPRNG) à la Debian ? Unlikely but the risks exists, so not going to happen in my opinion.
Re: Ok Google: please publish your DKIM secret keys
#86The comments here on Hacker News seem to have tripped on the examples given (keywords: politicians, journalists) and turned this into the more generic and politically loaded discussion whether it's desirable to "cryptographically verify" what politicians write.
But that's not the point! The point is that DKIM is technically not designed for this use case and the way people misuse DKIM for this unintended purpose is highly problematic from a cryptographic and engineering perspective.
I think the best way to think of DKIM is that it's a "cryptographic protocol" in the sense that git is a "cryptographic protocol" because it uses SHA1. If you think "PGP" (not the best example :-)) or "Telegram" you have the wrong idea: DKIM is a bunch of cryptographic primitives haphazardly bolted on email to solve a specific problem. It's not good cryptographic design because good cryptographic design anticipates unintended usecases and deal with them appropriately.
1) Read the DKIM RFC.
First of all the only field that it's required to sign is the From: header (see RFC, section 5.4). So you could still forge an email but have it pass a DKIM signature check.
If people believe that DKIM "cryptographically signs" e-mails in the sense of PGP, then that's a problem, because that's not true. A DKIM signed email doesn't actually say anything: you have to look at the signature which part of the message are signed, which is not standardized.
So you could have this situation when people, like journalists or even people on Hacker News, think a forged email is valid because it has a valid DKIM signature (but the signature is over the From: header only). E-mail is complicated as it is without having to explain to people who have binary classified an email as "forgery" or "not forgery" based on a specific combination of email-headers and DKIM signature specification. Let's not do that.
2) Look at what mail providers actually do with their DKIM keys.
For legacy reasons due to DNS providers and length of TXT records, many large internet providers use DKIM keys that are 1024 bit RSA.
Already 10 years ago, most standard bodies started to recommend against the use of 1024 bit RSA. It's deprecated. Like MD5-deprecated.
The fact that many service providers use the same key for all emails for all customers and reuse that key for years, increasing the likelihood of the key being leaked, is another case against trusting DKIM for this purpose.
Re: Ok Google: please publish your DKIM secret keys
#87Earlier quoted context omitted.
Among messaging cryptographers, it's not even an argument. Serious secure messengers have been designed to avoid non-repudiation since OTR. Non-repudiation is a vulnerability: once counterparties have authenticated each other's messages, the legitimate need for authentication is gone; allowing random strangers to authenticate messages concedes information to them. Here, have a link, from 2004: https://otr.cypherpunks…
> once counterparties have authenticated each other's messages, the legitimate need for authentication is gone; allowing random strangers to authenticate messages concedes information to them. As you know, there are many legitimate needs to authenticate messages of strangers. For example, when you order products over the internet, an e-mail of your purchase is often the only proof of what was agreed in the purchase.…
Re: Ok Google: please publish your DKIM secret keys
#88Earlier quoted context omitted.
> how do you get your head around disappearing messages? I mean I try to publish most of my interesting email conversations on the web, because every time you have a good email conversation that isn't public it's like taking a $100 bill and lighting it on fire. So I wouldn't ever personally use disappearing messages. Literally the first rule of email is that if you wouldn't want it on the front page of the NYT then y…
Then why don't we design such a system first with a higher level of guarantee first and inform users that this the goal.
Re: Ok Google: please publish your DKIM secret keys
#89Hey Google. Please never do this. This would throw thousands of evidence about how Erdogan regime worked with terror organisations, including the e-mails that tried to ban social media to stop these evidences be available to public. And also how they declared innocent people as terror organisations with some companies that offered law support. For example, this one https://wikileaks.org/berats-box/emailid/35540 espec…
Re: Ok Google: please publish your DKIM secret keys
#90Earlier quoted context omitted.
> Non-repudiation over time is a truly powerful property of DKIM'd email for a great many uses outside of blackmail. This. Publishing the DKIM keys would be a huge loss for email archivists and historians in general. E.g. a couple weeks ago Donald Knuth published all of the emails he's sent and received over the last 20+ years of his career[1], without DKIM how would we know that they are authentic? [1] https://libra…
Do you mistrust the unsigned emails from 10+ years ago because they were sent prior to DKIM? As for authenticity, you could contact him, or his correspondents?
Yes.
> As for authenticity, you could contact him, or his correspondents?
Correspondents aren't necessarily going to tell the truth about the authenticity of their own email. And that's assuming they're alive, reachable, and willing to talk, all of which may not be the case now and will be the case with 100% certainty in the future.