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

251–260 of 492 posts

Re: Ok Google: please publish your DKIM secret keys

#251

Post by FrozenVoid »

rurban wrote: post #93
FrozenVoid wrote: post #22

A novel type of cryptographic attack "Begging Google to release their secret keys on HN"[2020]

So I thought Google was already CIA for a long time. But now a CIA shill (or NSA) has to resort to a public plea to remove email authentication, so that future embarrassing email leaks, probably proving corruption and other criminal activity, can easily be plausibly denied. Wtf. Even for old emails, gmail break-ins. They are getting more and more laughable. What about a public plea for justice? Accountability?

Equating something to a CIA front company is too simplistic(like Zuckerberg's Facebook and Lifelog project), the companies, projects and frameworks grow out of their sponsors reach and evolve into large, complex systems like the Internet(a spin-off from ARPANET created by Advanced Research Projects Agency (ARPA) of the United States Department of Defense ).

Re: Ok Google: please publish your DKIM secret keys

#252

Post by 1vuio0pswjnm7 »

"The problem with DKIM is that no customers asked for this feature as a default in their commercial mail account."

Two questions:

Have there ever been any Gmail design decisions, e.g., default settings, where users were consulted first?

I was recenty informed by another HN commenter that "99% of users" are "not qualified to have opinions" on something like MacOS behaviour,[FN1] or in this case Gmail behaviour. If this is true, should "99%" of users be given the choice not to use DKIM if they are "not qualified" to have an opinion on DKIM?

1. https://news.ycombinator.com/item?id=25100342

Re: Ok Google: please publish your DKIM secret keys

#253

Post by brightball »

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…

Why not just rotate them frequently? Like weekly? Or daily even?

ProtonMail makes you setup 3 CNAMEs for DKIM just so they can frequently rotate without your intervention or disruption. Sendgrid uses 2 for the same thing.

Re: Ok Google: please publish your DKIM secret keys

#254

Post by [deleted] »

tptacek wrote: post #82

I know threads change over time, and it's dangerous to write a comment in response to the perceived gestalt of an HN thread, but, I have to say, it's pretty wild reading a thread on this site arguing so strenuously against the premise of secure messaging. In messaging cryptography, non-repudiability has for almost 2 decades been considered a vulnerability, not a feature. The OTR protocol[1] takes the step of publishi…

[deleted]

Re: Ok Google: please publish your DKIM secret keys

#255

Post by a1369209993 »

baobabKoodaa wrote: post #108
tptacek wrote: post #87

Earlier quoted context omitted.

No, you have confused messaging cryptography with "all of cryptography".

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 gave a example of a 'need' to do X that is specifically not legitimate. I'm not sure (and decline to speculate) whether you're confused or malicious or some other problem entirely, but you are wrong.

Re: Ok Google: please publish your DKIM secret keys

#256

Post by creeble »

The problem with the author's paper is that his assumption (and that of, apparently, media organizations, Wikileaks, and others) of DKIM "ensuring non-repudiation of emails" is simply wrong.

>DKIM provides a life-long guarantee of email authenticity that anyone can use to cryptographically verify the authenticity of stolen emails, even years after they were sent.

No, it doesn't. It simply offers an assurance that, at around the time of sending, a given email was mostly likely sent from the server that signed it. It can't prove _anything_ about who actually sent it, because it can't guarantee the ownership of the email account.

>For better or for worse, the DKIM authenticity stamp has been widely used by the press, primarily in the context of political email hacks. It’s real, it’s important, and it’s meaningful.

There's no _better_ there -- only for worse. It would be better to dispute the validity of using DKIM for non-repudiation of emails than to propagate the lie and ask server operators to publish their expired secret keys.

Re: Ok Google: please publish your DKIM secret keys

#257

Post by tomc1985 »

brightball wrote: post #253
tptacek wrote: post #55

Earlier 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…

Why not just rotate them frequently? Like weekly? Or daily even? ProtonMail makes you setup 3 CNAMEs for DKIM just so they can frequently rotate without your intervention or disruption. Sendgrid uses 2 for the same thing.

What's stopping someone from recording each public key as it is entered into service and providing a DKIM authentication service with it? There are already such things for domain data.

Re: Ok Google: please publish your DKIM secret keys

#258

Post by tigger0jk »

syrrim wrote: post #159
tptacek wrote: post #82

I know threads change over time, and it's dangerous to write a comment in response to the perceived gestalt of an HN thread, but, I have to say, it's pretty wild reading a thread on this site arguing so strenuously against the premise of secure messaging. In messaging cryptography, non-repudiability has for almost 2 decades been considered a vulnerability, not a feature. The OTR protocol[1] takes the step of publishi…

It's easy to see why there are divided opinions on this. When someone sends an email, the recipient often wants to be able to prove that they did so. We think of email as something capable of leaving a paper trail, proof that certain people sent certain emails. It's reasonable for secure messaging to want to fill a different niche, more like private conversation. I've seen messaging apps advertised on the basis that…

I appreciate the re-framing of this comment and its parent. Personally I found the original article's argument to feel more like "people shouldn't be accountable for their correspondence" than "the default mode of email should be more of private secure messaging". Both are advocating for the same changes but only one seems reasonable to me. That may just be my flawed reading of the blog post, but regardless, I can better understand the positions now.

Re: Ok Google: please publish your DKIM secret keys

#259

Post by feanaro »

tptacek wrote: post #186
feanaro wrote: post #183

Earlier quoted context omitted.

> 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.

Yes, I'm not disagreeing with you. Non-repudiability should be an explicit design point in protocols that need it.
Post reply on HN