Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ok Google: please publish your DKIM secret keys

blog.cryptographyengineering.com

Post reply on HN
Print view View original

181–190 of 492 posts

Re: Ok Google: please publish your DKIM secret keys

#181

Post by woodruffw »

beagle3 wrote: post #156
woodruffw wrote: post #138

Earlier quoted context omitted.

> ..... so? That means in 2016, the DKIM was already deniable. And it made no difference whatsoever. Both journalists and investigative groups (and conspiracy theorists) treat DKIM as a sign of authenticity, even when the key material is long past its prime. Wikileaks still prominently displays a "verified" marker next to their archives. > Did DKIM change anything about the podesta emails? Or were they basically ackn…

I don’t understand the fascination with DKIM on this thread. Yes, journalists verified it. But they consider it supporting data, just as they wouldn’t automatically ignore any email that had no DKIM signature. Phone calls are never authenticated. Does anyone automatically believe or disbelieve recorded phone calls? I mean, “conspiracy theorists” (in the common usage of that terms) already believe only what they want…

I don't think it's a fascination, it's what the OP is about. We're talking about the subject of a blog post, no?

I think the point boils down to expectation management: journalists (and ...) barely understand non-repudiation, much less why each of the following scenarios pans out:

* 2006 email + 512-bit RSA, leaked in 2006: probably authentic

* 2008 email + 512-bit RSA, leaked in 2012: potentially inauthentic

* 2008 email + 1024-bit RSA, leaked in 2008: probably authentic

* 2008 email + 1024-bit RSA, leaked in 2016: potentially inauthentic

...and so on. In sum: we're making life harder for the people doing real investigative work (since they're not technical), and we're giving fodder to the people who want to conspiracize. All because we're using a spam mitigation technique to provide properties that it was never intended to provide.

Re: Ok Google: please publish your DKIM secret keys

#182

Post by mthoms »

hashtagmarkup wrote: post #152
mthoms wrote: post #139

Earlier quoted context omitted.

Huh? No one (including yourself), have mentioned anything about "destruction of evidence" so far. If you care to enlighten me about how it's relevant I'm happy to listen.

By making the DKIM keys public, you are converting solid evidence of something that was said into something that was either really said, or someone else pretended that they said. Evidence was destroyed.

This describes all encrypted and short lived messages.

Edit: Removed the word "literally" because it was incorrect and caused distraction from the actual argument.

Re: Ok Google: please publish your DKIM secret keys

#183

Post by feanaro »

baobabKoodaa wrote: post #161
tptacek wrote: post #137

Earlier quoted context omitted.

It's just really clear that people in this thread are trying to approach this from first principles without any engagement in the field that they're discussing. That's a fun thing to do as, like, a game or a way to pass the time, and I guess that's what HN is, but it's still crazymaking, because essentially every paper written about messaging cryptography refutes this comment. Cryptographers would like to move people…

Ok, my GPG example was wrong. And yes, you got me, I'm not a professional cryptographer. But can you address the point? You said "once counterparties have authenticated each other's messages, the legitimate need for authentication is gone". I provided a counter-example to demonstrate that your statement was an exaggeration. You clearly dispute some part of this, but it's unclear to me what the disputed part is. Edit:…

> I provided a counter-example to demonstrate that your statement was an exaggeration.

Which counterexample is that exactly? Your counterexample involving a store is incorrect -- the store's email would still be authenticated for a smaller amount of time which would allow your server to verify that it is a valid email that came from the store's servers.

EDIT: Since you responded with an edit, I suppose I should as well. Btw, you can reply to comments below, but you have to click on the comment's permalink/timestamp (the thing that says "1 hour ago") first.

I didn't see the comment you are referring to because it was a very high up ancestor. I only saw the comment I replied to which doesn't mention courts nor third-parties, which is why I asked you for an explanation. Please don't jump immediately to the conclusion that I did not read your comment.

Regarding the content, hamburglar's sibling comment is spot on. Non-repudiability shouldn't just be an afterthought. Accidental non-repudiability can have negative consequences itself. For one, relying on the kind of poor man's non-repudiability that DKIM gives you leaves powerful central entities with the ability to forge email while convincing almost everyone that it is legitimate.

From reading everything that you wrote, I think that your thesis is that email, specifically, ought to be non-repudiable. That might be a worthwhile idea, but it should be presented as such at the forefront. If others agree that this is a valid and useful concept, then a non-repudiability mechanism could be added to email explicitly, just as DKIM was added. But don't use DKIM for this, since it is a poor substitute.

Re: Ok Google: please publish your DKIM secret keys

#184

Post by baobabKoodaa »

mirashii wrote: post #143
baobabKoodaa wrote: post #108

Earlier quoted context omitted.

You said "there is never a legitimate need to do X". I gave an example of a legitimate need to do X. Your rebuttal is that... I'm confused? Yeah, you're gonna have to be more specific than that if you want to convince anybody.

> You said "there is never a legitimate need to do X". No, he didn't, and to use quotes to claim someone said something that they didn't say is extremely disingenuous.

Here is the actual quote: "once counterparties have authenticated each other's messages, the legitimate need for authentication is gone". Yes I used quotes in the "do X" sentence, but nobody will mistake it for a literal quote, because it contains "X" in place of the actual thing. Anyway, do you think there is something wrong with my characterization of that statement?

Re: Ok Google: please publish your DKIM secret keys

#185

Post by shinigami »

landryraccoon wrote: post #147

Wow. This blog post is appalling. I completely disagree with it. Consider this excerpt from the blog post: > But DKIM authenticity is great! Don’t we want to be able to authenticate politicians’ leaked emails? > Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns. An accident of the past few years is tha…

We could catch a lot of criminals if we every OS had a backdoor that the police could access. So, are you in favor of that?

Re: Ok Google: please publish your DKIM secret keys

#186

Post by tptacek »

feanaro wrote: post #183
baobabKoodaa wrote: post #161

Earlier quoted context omitted.

Ok, my GPG example was wrong. And yes, you got me, I'm not a professional cryptographer. But can you address the point? You said "once counterparties have authenticated each other's messages, the legitimate need for authentication is gone". I provided a counter-example to demonstrate that your statement was an exaggeration. You clearly dispute some part of this, but it's unclear to me what the disputed part is. Edit:…

> I provided a counter-example to demonstrate that your statement was an exaggeration. Which counterexample is that exactly? Your counterexample involving a store is incorrect -- the store's email would still be authenticated for a smaller amount of time which would allow your server to verify that it is a valid email that came from the store's servers. EDIT: Since you responded with an edit, I suppose I should as we…

Non-repudiability makes perfect sense in a bunch of different financial cryptography settings. People really have trouble with the idea that all cryptography isn't the same, and that it's specialized to different problem domains. It's part of the reason we still have janky old PGP.

Re: Ok Google: please publish your DKIM secret keys

#187

Post by [deleted] »

landryraccoon wrote: post #147

Wow. This blog post is appalling. I completely disagree with it. Consider this excerpt from the blog post: > But DKIM authenticity is great! Don’t we want to be able to authenticate politicians’ leaked emails? > Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns. An accident of the past few years is tha…

[deleted]

Re: Ok Google: please publish your DKIM secret keys

#188

Post by landryraccoon »

tptacek wrote: post #164
landryraccoon wrote: post #147

Wow. This blog post is appalling. I completely disagree with it. Consider this excerpt from the blog post: > But DKIM authenticity is great! Don’t we want to be able to authenticate politicians’ leaked emails? > Modern DKIM deployments are problematic because they incentivize a specific kind of crime: theft of private emails for use in public blackmail and extortion campaigns. An accident of the past few years is tha…

The word "appalling" describes something that creates surprising distress or dismay (itself implying surprise). To be surprised at a cryptographer advocating for deniable messaging is to suggest that you're unacquainted with the field of messaging cryptography, in which deniable messaging has been a foundational goal for almost 2 decades, going back to Ian Goldberg and Nikita Borisov, who once yelled at me on Twitter…

In the quote I presented above, the author wasn't making a technical argument, but a moral one.

If you or the author are presenting an argument why repudiation is necessary on technical grounds, I will admit ignorance and defer to the experts.

But my reading of the blog post was that it is not a technical argument. It's an argument about morality, and specifically the author used political examples. If the author did not want lay people to argue about the moral implications, why did they use non-technical arguments?

Re: Ok Google: please publish your DKIM secret keys

#189

Post by saurik »

tptacek wrote: post #55
xbar wrote: post #25

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?

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…

FWIW, I am pretty sure I agree with you/OTR, but the IETF Messaging Layer Security (MLS) people disagree for not-always-trivially-dismissible reasons (indirect link because I am lazy).

https://news.ycombinator.com/item?id=25101825

Re: Ok Google: please publish your DKIM secret keys

#190

Post by hyperpape »

adrianmonk wrote: post #174
hyperpape wrote: post #50

Earlier quoted context omitted.

Your threat model appears to be that most email providers are hacked a substantial percent of the time, right? What defenses of anything are going to work with that threat model?

You don't necessarily have to hack the provider. You can hack the user's laptop and siphon the data out of their email client. If they use a web client, you can read the files it caches. Or maybe you can set up IMAP and have your malware read a copy of everything. To the email provider, all of this just looks like the user is reading their email.

Fair, though I think it's still true that it's a very difficult threat model.

Also worth noting that email clients typically tell you about new logins/clients (though I don't think their way of doing it is particularly robust).

Post reply on HN