[HN Gopher] Ok Google: please publish your DKIM secret keys
___________________________________________________________________
Ok Google: please publish your DKIM secret keys
Author : Reventlov
Score : 311 points
Date : 2020-11-16 16:22 UTC (4 hours ago)
(HTM) web link (blog.cryptographyengineering.com)
(TXT) w3m dump (blog.cryptographyengineering.com)
| 7ewis wrote:
| Repudation - "denial of the truth or validity of something."
| FrozenVoid wrote:
| A novel type of cryptographic attack "Begging Google to release
| their secret keys on HN"[2020]
| rurban wrote:
| 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?
| FrozenVoid wrote:
| 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 ).
| elaborant wrote:
| Key disclosure by cryptographic shaming[2020]
| 867-5309 wrote:
| even after spending countless hours configuring SMTP, SSL, TLS,
| SPF, DMARC, DKIM, IP address pools, white/blacklists, etc. there
| is still a 99% chance secure, authorised, authenticated,
| "signed", sealed email will be delivered to a spam folder
|
| so what's the point?
| tptacek wrote:
| 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 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._
| moyix wrote:
| Has this kind of repudiation ever been tested in the real
| world? It's hard to imagine a court throwing out email evidence
| because it lacked a DKIM signature. And on a personal level
| seeing a chat transcript that had cryptographic non-repudiation
| would make me likely to believe it, but seeing one that
| _lacked_ it would probably not weigh heavily in how I came to
| that determination.
| some_furry wrote:
| > Has this kind of repudiation ever been tested in the real
| world? It's hard to imagine a court throwing out email
| evidence because it lacked a DKIM signature.
|
| They're more likely to ask their expert witness to testify
| about the evidence, and the deniability of the DKIM signature
| could be brought up by the expert witness as a reason to
| distrust the evidence. I wouldn't expect lawyers to discover
| this argument from first principles.
|
| Has it ever happened? Not that I know.
| moyix wrote:
| The success of the "trojan defense" is encouraging on this
| point, I guess:
|
| https://en.wikipedia.org/wiki/Trojan_horse_defense#Cases_in
| v...
|
| I'm sure defense lawyers would love it :)
| syrrim wrote:
| 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 they will
| delete all messages after a certain time, making them basically
| equivalent to talking to someone, in terms of non-repudiation
| and being ephemeral by default. But people frequently want
| email to be more like letter writing than private conversation.
| The tradition with letters was to sign your letters to prove
| that you sent them. People talk about having a certain thing
| "in writing", so that they can use it in litigation. Insofar as
| email is supposed to fill that niche, its reasonable to expect
| it to provide repudiable messaging.
| tptacek wrote:
| My problem isn't that people have divided opinions on this.
| My problem is that people who oppose it write as if they're
| just now discovering that the opposite opinion exists --- in
| one case on this thread, someone suggested that the only
| reason Matthew Green held this opinion at all was political.
|
| A serious argument against deniable messaging would start by
| acknowledging deniability as one of the shibboleths of the
| field of messaging cryptography, and _then_ tackle the idea.
| Nobody on this thread has done that, and I think the reason
| why is that they 're simply not aware that there is such a
| field.
| tigger0jk wrote:
| 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.
| [deleted]
| mehrdadn wrote:
| > Once counterparties have authenticated each others messages,
| authentication has served its purpose.
|
| Except this is easier said than done if you're publishing your
| keys. If Google publishes its keys, how would a third-party
| hosting service prove to its user that it hasn't tampered with
| the message in transit?
|
| How can that _user_ even authenticate that the message and
| verify it was sent by Google?
|
| They can checking the timing (that they received it before the
| keys were rotated), but this will fail for the emails sent
| around the same time as the rotation. And without saving a
| local copy at that time (ensuring physical security), they will
| no longer be able to verify it _themselves_ , let alone prove
| it to anyone else.
|
| Moreover, they have to trust that their hosting provider
| doesn't tamper with messages (which normally it wouldn't, but
| with high stakes it might), and they also have to trust that
| their inbox will never get hacked.
|
| In other words, this seems to weaken the security of DKIM
| authentication for the counterparties parties themselves
| considerably--not just for third parties.
| FrozenVoid wrote:
| The problem of deniability and "disavowing keys" is subjective
| and requires technical skill to understand, that average person
| will not find this "equalization of legit and forged data"
| intuitive and will believe that keys/signatures/encryption on
| content adds authenticity on equal level with "legit data" -
| instead of "repudiation" you have a 'weak proof of
| authenticity' that _could_ be disproved later(the burden of
| proof shift here is important psychologically since keys
| /encryption are perceived as legitimizing content).
| sethgecko wrote:
| Excuse my ignorance but how does someone else signing my
| message prove that I sent the message? Moreso if the body of
| the message is not being signed at all?
| shinigami wrote:
| Good luck arguing that Gmail forged and signed an email from
| you.
| speedgoose wrote:
| I doubt Google will publish old private keys that were not
| designed to become public later. I would guess that it's too
| dangerous or cumbersome to do the security analysis.
|
| What if someone realizes that Google uses a broken
| cryptographically secure pseudorandom number generator (CSPRNG) a
| la Debian ? Unlikely but the risks exists, so not going to happen
| in my opinion.
| toast0 wrote:
| It's also quite possible that they simply deleted the private
| keys after cycling to new keys.
| benlivengood wrote:
| Only the recipient has access to the DKIM signatures. If
| something is politically worth leaking then it's worth signing
| and time-stamping. At least then there's no question that it's
| the legitimate email and not falsified.
| xbar wrote:
| 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?
| bluu00 wrote:
| your arguement seriously makes the whole _privacy arguement_
| seem futile.
|
| what about a _telegram_ message?
| hyperpape wrote:
| "An accident of the past few years is that this feature has
| been used primarily by political actors working in a manner
| that many people find agreeable -- either because it suits a
| partisan preference, or because the people who got "caught"
| sort of deserved it.
|
| But bad things happen to good people too. If you build a
| mechanism that incentivizes crime, sooner or later you will get
| crimed on."
| tigger0jk wrote:
| People who are protected from blackmail by email repudiation
| are by definition people who have incriminating emails. Maybe
| everyone had skeletons in their closet, but if you have email
| proof of skeletons I'm starting to wonder if you're such a
| good person.
|
| Also there's an argument that "good people" can be
| blackmailed for INVENTED misconduct, but wouldn't such fake
| emails be more convincing without the ability to verify their
| origins? Making real emails and fake emails more similar
| protects people who have their incriminating emails leaked,
| but it also harms the defence of people who have fake emails
| targeting them "leaked".
|
| There's a high bar for obfuscating truth and I don't believe
| this argument meets it.
| thinkharderdev wrote:
| I don't think the implication that only "bad" people can be
| blackmailed is valid. You could be blackmailed for being a
| homosexual in many parts of the US still or doubting the
| existence of god or having unacceptably conservative
| political views. We do all sorts of things that are not at
| all wrong but may carry a significant social or economic
| cost if they were to be exposed publicly.
| scarmig wrote:
| The world isn't entitled to knowing whether something I'm
| alleged to have said or done really happened or not.
|
| For the people who lack imagination: suppose I'm a public
| official, and a photograph comes out depicting me doing
| some kind of "dirty" sexual act. Maybe it's real; maybe
| it's a deepfake; but if confirmed to be real it certainly
| would do reputational damage. Non-repudiation by definition
| prevents me from disavowing it, to no social benefit, and
| it's an anti-feature, in the sense that the large majority
| of users would prefer to have the ability to repudiate
| certain message contents than not.
|
| Non-repudiation should be opt-in.
| avianlyric wrote:
| Ah yes, the good old, "If you haven't done anything wrong,
| you've got nothing to hide" argument. The authoritarians
| favourite argument for a police state.
|
| I guess you're the type of person that would happily hand
| over all your personal files to the police on a regular
| basis as you have nothing to hide.
| zo1 wrote:
| Not OP. But I _would_ give all my data to the police
| /government... in an encrypted manner that has guarantees
| in place that only valid criminal investigations can
| decrypt. Heck, we do it on some level all the time
| anyways when it comes to things such as filing taxes,
| getting married, running companies, enforcing contracts
| and various other day-to-day benign interactions.
|
| At this point, I'm more inclined to believe that
| "democratic" and "noble" governments and agents are the
| ones maliciously pushing for "privacy" because it suits
| their power-maintaining agenda. I'm struggling to find
| compelling and valid reasons why we can't pursue a
| general solution that involves us giving all this
| "private" data to a government entity for legitimate
| investigations, fraud prevention and crime-solving whilst
| keeping that data free from abuse.
| int_19h wrote:
| Because we don't trust the government agents to provide
| such guarantees, or to honor them if they do?
| earthboundkid wrote:
| > I'm struggling to find compelling and valid reasons why
| we can't pursue a general solution that involves us
| giving all this "private" data to a government entity for
| legitimate investigations, fraud prevention and crime-
| solving whilst keeping that data free from abuse.
|
| Because that's not logically possible. It would be nice
| if it were, but just think about it: if you give data to
| the government, humans can look at it. Can we ensure that
| the humans who look at it are good humans? No. Is there
| some mathematical way of signing and encrypting such that
| only good humans can look at it? No.
|
| Okay, so it's logically impossible to keep bad people out
| mathematically, but maybe it's a practical problem and it
| doesn't matter in practice? Except no, there are tons of
| evil governments (CCP being the most obvious, but pick
| your poison), and even good governments are subject to
| the problem that people can bribed and secrets can be
| stolen if there is sufficient motivation. It's just not
| compatible with human nature to say "collect all this
| information on people, but only use it For Good
| Purposes."
| harikb wrote:
| Please read the whole article. If it only takes a "few
| hours" to create incriminating "evidence" (read, something
| that didn't exist) - it must be clearly proclaimed as such
| to the world.
| tigger0jk wrote:
| I believe you are referring to this quote (correct me if
| not): "In fact, in the early DKIM configurations were
| kind of a joke: mail providers chose DKIM signing keys
| that were trivial for motivated attackers to crack. Back
| in 2012 a security researcher named Zachary Harris
| pointed out that Google and several other companies were
| using using 512-bit RSA to sign DKIM. He showed that
| these keys could be "cracked" in a matter of hours on
| rented cloud hardware, and then used these keys to forge
| emails from Larry and Sergey.
|
| Providers like Google reacted to the whole "Larry and
| Sergey" embarassment in the way you'd expect. Without
| giving the implications any serious thought, they quickly
| ramped up their keys to 1024-bit or 2048-bit RSA. This
| stopped the forgeries, but inadvertently turned a
| harmless anti-spam protocol into a life-long
| cryptographic authenticity stamp -- one that can be used
| to verify the provenance of any email dump, regardless of
| how it reaches the verifier."
|
| Note that the "few hours" attack here is only relevant if
| they were using easily crackable 512-bit keys. The author
| of this article suggests (and I agree) that the 1024 or
| 2048 bit RSA keys are not easily crackable. (see
| https://crypto.stackexchange.com/a/42830)
|
| Maybe you are suggesting that someone could sign emails
| using the old crackable 512-bit keys. And they could,
| although we should disregard this as "not verification"
| given the weak keys. The article links to
| https://github.com/robertdavidgraham/hunter-dkim#short-
| dkim-... - which verifies an email using a since-rotated
| 2015 key (which was 2048 bits), although that github
| erroneously states that Google was using 1024 bit before
| that (they were using 512).
|
| I would concede that the notion of "sometimes we should
| disregard some DKIM verifications based on the key
| length" is not easy to grasp and that email verification
| stories in the media could become muddier and harder to
| present. I would hope that interviewing experts gets you
| a reasonable estimation of how likely an email is to be
| legitimate.
| kmeisthax wrote:
| This fails the role-reversal test. If Donald Trump had his
| e-mails leaked in 2016, the blackmailer would likely have
| extorted a ransom payment from then-candidate Trump. He paid
| off Stormy Daniels, after all. Nobody would have gotten any
| juicy e-mail dumps, and some criminals would have had actual
| leverage over politicians. Just because Hillary Clinton was
| less shrewd than Donald Trump does not mean that blackmail
| material is good for us as citizens just because some
| politicians don't pay ransoms on principle.
|
| If you want transparency from your politicians, then you should
| demand unconditional archival and publication of campaign
| e-mails. Build transparency into the system. Leakers are not
| archivists, nor are they journalists. They are leakers, with an
| entirely different set of motivations and incentives which only
| sometimes align with journalistic or archival motivations. You
| as a member of the public will not hear about leaks if the
| person in possession of those leaked files has successfully
| extorted or ransomed the politician they came from. In this
| particular threat model, DKIM does not provide a social benefit
| to you as a citizen, it provides a monetary benefit to the
| leaker.
| maest wrote:
| A counter to the non-repudiation of old emails is the fact that
| people who own their own mail servers can rotate their DKIM
| keys. So it's already possible for e.g politicians to have
| their email set up in such a way that they're insulated from
| leaks.
|
| The argument here is more that customers of gmail and other
| email services are not offered repudiation as a feature.
| gowld wrote:
| "Rotating keys" isn't the important part. "Publishing keys"
| is the important part. "Rotating keys" is an implementation
| requirement of "DKIM with repudiability via eventually-
| published keys."
| londons_explore wrote:
| OP's argument is if you care about this enough, you can set
| up your own mail server, rotate and publish your own keys
| on whatever schedule you like.
| harikb wrote:
| Please read the whole article before jumping into a conclusion
| about the author, Matthew Green. He sighted two examples where
| incorrect crypto science affected both a Democrat and a
| Republican. He is not trying to protect any particular side. He
| is simply articulating a method by which the key can be
| invalidated after its intended life time. If you have a
| technical argument, please explain that.
| simias wrote:
| I don't know how I feel about it but I do think it's an
| interesting argument. The point of DKIM is, first and foremost,
| to fight spam. The non-repudiation aspect is, as far as I'm
| concerned, a side effect of DKIM, not a core feature.
|
| The more I think about it the more I inch towards agreeing with
| TFA. If I need my email to be authenticated I can sign them
| with GPG. If the law enforcement needs to see if I did or did
| not send an email they can subpoena Google.
|
| >Non-repudiation over time is a truly powerful property of
| DKIM'd email for a great many uses outside of blackmail.
|
| Can you expand on this? I can't really come up with a use case
| that wouldn't be about associating somebody with an email they
| may want to distantiate themselves from.
| ChuckMcM wrote:
| Except, as pointed out in the article, over time the ability to
| crack the underlying key and thus forge such emails becomes
| very practical. By disavowing the keys it prevents someone from
| taking a cracked key, forging an email and then "discovering
| it" for nefarious purposes.
| tzs wrote:
| Disavowing also protects against key theft or leaks. I'd
| guess that theft or leaks are probably more likely than
| cracking, now that the major providers are using long keys.
| zajio1am wrote:
| > 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.
| chimeracoder wrote:
| > 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.
| thinkharderdev wrote:
| Not to mention that DKIM only validates that en email was
| sent with particular content from a particular email
| address. It cannot ensure who was actually sitting at the
| keyboard composing the email.
| amadeuspagel wrote:
| > If that were the case, courts wouldn't be able to enforce
| contracts with wet signatures (which are straightforward to
| forge)
|
| I'm pretty confident that I could sign an email with a DKIM
| key if that were published, however, there's nothing that
| would give me the confidence that I could forge a pen
| signature in such a way that not even an expert could
| detect the forgery.
|
| > or verbal contracts (which are valid contracts and
| regularly enforced).
|
| I'm not a a lawyer, but according to the first google
| result "the Uniform Commercial Code [...] requires that
| contracts for the sale of goods over $500 to be in
| writing".[1]
|
| > Disputes over whether the text of the executed contract
| is authentic are rare in real life.
|
| Maybe they are rare precisely because it's hard and risky
| to forge signatures.
|
| [1] https://www.hg.org/legal-articles/are-verbal-
| agreements-bind...
| pdonis wrote:
| _> the Uniform Commercial Code [...] requires that
| contracts for the sale of goods over $500 to be in
| writing_
|
| Yes, but not all contracts do that. For example, any
| contract for _services_ is not covered by the UCC.
| shinigami wrote:
| Entering an contract via an email is a ridiculous idea from
| the start.
| xyzzyz wrote:
| That's right, we need more travel and in-person meetings
| now.
| bartvk wrote:
| I don't know about your country, but in mine (The
| Netherlands), it is a completely and utterly valid way to
| enter a contract.
|
| Actually, you are free to enter a contract in any way
| possible. It is vormvrij (translated: form-free). Excluded
| is the purchase of a house, as far as I know. But for the
| rest, you are free to come to an agreement via WhatsApp,
| Facebook, email, or a scrawl on a piece of paper.
| schoen wrote:
| In the U.S., many contracts (but not all) can in
| principle by default be oral and still be enforceable by
| law.
|
| https://smallbusiness.findlaw.com/business-contracts-
| forms/w...
| anticristi wrote:
| Same in Sweden. "Are you okey with paying extra for X?"
| "Yes, please go ahead."
|
| And that's how a new contract gets signed! No need to fly
| someone 1500km just for that.
| icedchai wrote:
| Would you prefer we use fax machines instead?
| Quarrel wrote:
| wtf? it happens all the time.
|
| I've raised VC money based on emailed contracts, bought
| businesses based on them, bought domain names.
|
| It is incredibly standard and legal (in almost all of the
| jurisdictions I've worked in, which is a lot).)
| avianlyric wrote:
| If non-repudiation is important to you, then both parties
| should consent to it and use a platform that explicitly
| supports it.
|
| It shouldn't be sprung on people without consent. It would be
| like saying it's fine to keep a recording from someone else's
| webcam because it might prove a crime later.
|
| There's a reason why justice systems have statues of
| limitations. People should need to look over their shoulders
| for the rest of their lives because of one poorly written
| email.
| quit32 wrote:
| It is not really being sprung on them with how long it has
| existed. Not at all like continuing recording on a webcam
| where you might say things never intended for the party
| receiving it.
|
| Are ppl who don't even know DKIM exists but know they have
| shady emails saved in the cloud or on their personal really
| just banking on repudiation and thats why they take no
| other action like deleting the email or putting more
| thought into emails they send? Seriously doubt it.
|
| Exactly bc of statute of limitations, they would not have
| to look over their shoulders for the rest of their lives
| because of one poorly written email.
| thinkharderdev wrote:
| I think it is less about user behavior and understanding
| than it is about the incentives it creates for nefarious
| actors. Basically, if emails can't be cryptographically
| verified then stealing a bunch of emails and anonymously
| dumping them somewhere is pointless since most people
| would probably not consider them authentic.
| quit32 wrote:
| Yes. I have seen first hand where it was used to help
| accelerate out of court agreement without needing a lawsuit.
| Basically a 3rd party had one of their outlook user accounts
| compromised by a bad actor who used it to tell another
| company new instructions for something.
|
| The 3rd party tried to say other company fell for a phishing
| email and it was their fault but because of DKIM it was
| immediately provable that instead 3rd party was compromised
| and email legit sent from their o365 and they were pretending
| like they didn't know this. This all got disputed maybe a
| year after email sent.
|
| Love Matthew Green but I personally am not a fan of this
| proposal. It doesn't fully achieve what he wants bc its only
| gmail and timing of compromise would be key. Most of the
| email hacks have actually been very much in the public
| interest despite being unethical. Breaches also lead to more
| productive work by companies in better securing accounts and
| better protecting sensitive information which google has been
| doing with account security and adding expiring messages.
|
| Like do we really want companies to just continue sloppily
| sending customer info in email bc they can deny its legit or
| should they focus on not getting this info compromised to
| begin with?
|
| Also, for ransomeware groups that now post data when not
| paid, it is not really seeming like too big of a disincentive
| that there is repudiation regarding the files they post.
| [deleted]
| secondcoming wrote:
| I think he's referring to this?
|
| https://www.trumpaccountability.net/
| gowld wrote:
| That website's owners already abandoned the project under
| suspicious pretenses of "unity".
| tptacek wrote:
| 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.ca/otr-wpes.pdf
| EGreg wrote:
| I do have a question though, as a relative amateur. It's more
| on a sociological level.
|
| Suppose you are in an organization, and it needs to figure
| our whether an employee was saying a Bad Thing such as giving
| out company secrets or cursing people out "off the record".
|
| Yes, even with end to end encryption, Facebook and others can
| still let you prove the other person sent the messages when
| you need. The question is whether that is a good thing:
|
| https://facebook.com/help/messenger-app/1165699260192280
|
| My personal feeling is yes, yes it is. I make a more
| extensive analysis here:
|
| https://news.ycombinator.com/item?id=25030085
| brightball wrote:
| 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.
| tomc1985 wrote:
| What's stopping someone from recording each public key as
| it is entered into service and providing a DKIM
| authentication service with it?
| baobabKoodaa wrote:
| > 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. If there is later a dispute between
| the buyer and the seller, the email can be used to repudiate
| lies. In particular, if a third party (like a court) can
| authenticate the message, the honest party can convince the
| third party that the dishonest party is being fraudulent.
|
| You are exaggerating when you claim that there is no
| legitimate need to authenticate messages as a third party.
| tptacek wrote:
| No, you have confused messaging cryptography with "all of
| cryptography".
| baobabKoodaa wrote:
| 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.
| ska wrote:
| The point was that you pointed out a use case for some
| sort of cryptographic signing, not for (ab-) using DKIM
| for this purpose rather than what it was designed for.
|
| I don't understand enough about all the issue to really
| know how I feel about it, but clearly there are trade-
| offs here that at least argue against expanding the
| scope.
| baobabKoodaa wrote:
| > His point was that you pointed out a use case for some
| sort of cryptographic signing, not for (ab-) using DKIM
| for this purpose rather than what it was designed for.
|
| First, thank you for the clarification.
|
| Second, to answer tptacek's point, I understand that
| authenticating emails as a third party is an unintended
| side effect of the DKIM protocol. I understand that
| cryptographers would like people to move onto using other
| protocols for purposes like this. However, the suggestion
| that Google should periodically publish and rotate their
| secret keys, does not achieve this goal in any way. If
| Google were to do this, the webstore that you purchase
| items from, would not suddenly start using different
| protocols to authenticate purchase receipts, they would
| continue to send regular email... but those emails could
| no longer be authenticated. Or if we go back to the
| example in OP, the politician that's admitting to crimes
| over email, they're certainly not going to switch over to
| another method of documenting their crimes.
|
| Edit: I was incorrectly using GPG as an example. I
| removed the incorrect example and let the point stand
| without it.
| tptacek wrote:
| 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 onto GPG? The
| fact that GPG is non-repudiable and shouldn't be is one
| of the 2 motivating use cases for OTR, and later Signal.
| Nobody is trying to get people to use GPG.
| baobabKoodaa wrote:
| 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: Hacker News doesn't allow me to post replies to the
| posts under this post, so I will answer by editing this
| comment. I'm addressing the following comment:
|
| > 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.
|
| If you actually read my counter example, you will see
| that I wrote: "if a third party (like a court) can
| authenticate the message".
|
| Yes, my email server can authenticate the email when it
| arrives, but that will be of little help later when I try
| to dispute claims in court. If the court can authenticate
| the email, that will be helpful to the honest party in
| the dispute.
| hamburglar wrote:
| > 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 ...
|
| I think the person you're talking to thinks this is very
| obvious and thus isn't stating it explicitly, but in the
| special case where you want an email to include non-
| repudiation, such as for a purchase receipt, the sender
| should just _add non-repudiation_ to it in the form of a
| signature that 's intended for that. Simple.
| baobabKoodaa wrote:
| > the sender should just add non-repudiation to it in the
| form of a signature that's intended for that. Simple.
|
| Ok, but this does not magically happen if Google
| publishes and rotates their DKIM keys. People will
| continue to use email for everything, but now emails can
| no longer be authenticated by third parties.
| hamburglar wrote:
| I think the entire point is that non-repudiation
| shouldn't just magically happen unless intended, so yes,
| this is by design, and anyone who wants to send a signed
| email should explicitly send a signed email.
| tptacek wrote:
| Start by reading the first sentence of my comment.
| feanaro wrote:
| > 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.
| tptacek wrote:
| 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.
| feanaro wrote:
| Yes, I'm not disagreeing with you. Non-repudiability
| should be an explicit design point in protocols that need
| it.
| mirashii wrote:
| > 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.
| baobabKoodaa wrote:
| 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?
| tptacek wrote:
| Yes, because it ignore the sentence that precedes it,
| which at this point you're doing wilfully.
| baobabKoodaa wrote:
| > Yes, because it ignores the sentence that precedes it.
|
| This sentence? "Serious secure messengers have been
| designed to avoid non-repudiation since OTR." I don't see
| how this sentence supposedly alters the meaning of the
| sentence that comes after it? At this point it seems like
| you just want to sow confusion. If I had misinterpreted
| your words in some way, you could have clarified the
| misunderstanding like 10 times by now. Instead, you
| choose to reply in snarks like saying I'm confused, or
| asking me to read your comment again. I don't think
| there's any misunderstanding. You took an extreme
| position that didn't hold up to scrutiny, and you don't
| want to defend your position or back down, so you just
| reply in snarks instead. If there is some kind of
| misunderstanding, please do go ahead and explain what the
| misunderstanding is.
| a1369209993 wrote:
| 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.
| hyperpape wrote:
| As you know, there are many legitimate needs to publish
| naked pictures of your body to the entire internet, but
| most people want to keep them private. Defaults matter.
|
| What makes this hard is that email is responsible for too
| much crap. No single user interface should carry:
|
| 1. Party invites
|
| 2. Private messages to your spouse, therapist, pastor, etc.
|
| 3. Marketing messages
|
| 4. Password recovery requests
|
| 5. Financial transactions
|
| We've just shoved them all into email because it's there.
| baobabKoodaa wrote:
| I agree that e-mail is horrible, and I would prefer if
| contracts (like purchase receipts) moved off e-mail to
| something else, but that's tangential to the point. If
| Google started to publish and rotate DKIM keys, the world
| wouldn't suddenly move away from email.
| red_trumpet wrote:
| > As you know, there are many legitimate needs to
| authenticate messages of strangers.
|
| I agree with you here. However, EMail was never designed to
| do this. Eg if you order products over the internet, how do
| you know that your opposing party keeps their DKIM key
| safe?
| baobabKoodaa wrote:
| > I agree with you here. However, EMail was never
| designed to do this. Eg if you order products over the
| internet, how do you know that your opposing party keeps
| their DKIM key safe?
|
| I get that email and DKIM was never designed for this,
| it's a side effect. Fingers were not designed for finger
| print evidence, but it's still nice to have evidence from
| finger prints, as a side effect from touching things. And
| the problem of key storage / keys leaking will not
| disappear even if you change to some different protocol.
| pwlb wrote:
| This sounds like a Law&Order mindset. No, its generally
| not a great idea to get fingerprints of everything.
| lxgr wrote:
| > As you know, there are many legitimate needs to
| authenticate messages of strangers.
|
| Absolutely, but this should be an opt-in feature.
| Red_Leaves_Flyy wrote:
| >this should be an opt-in feature (and not provided
| server-side, at that).
|
| Why?
| lxgr wrote:
| It just feels like the baseline expected behavior of a
| communications system to me that makes no explicit claims
| otherwise.
|
| Legal signatures are heavily ritualized (blue/black ink
| only, initial here and sign there etc.) in most societies
| for good reason - it makes the signer stop for a moment
| and reconsider what they are doing, if the document they
| are signing is truly aligned with their intentions and so
| on.
|
| As another analogy/food for thought: We have the
| technical means to record every conversation we ever
| have, digital or analog, public or private. Should we? If
| not, why not?
| saurik wrote:
| 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
| tptacek wrote:
| (a) I wasn't aware of this.
|
| (b) Thanks for the link!
|
| (c) The IETF is such a shitshow for cryptography.
| upofadown wrote:
| Cryptographers don't have some sort of monopoly on what is
| right or what makes sense. The idea of deniability as some
| sort of desirable feature in messaging came out of nowhere.
| It wasn't anything that anyone asked for or worried about
| before the OTR proposal suggested it.
| dannyw wrote:
| Cryptography should benefit the users.
| Alex3917 wrote:
| > 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://library.stanford.edu/blogs/special-collections-
| unbou...
| tptacek wrote:
| You can say the exact same thing about all secure messaging,
| which, after all, has the essential function of keeping
| documents out of the hands of third parties, including
| activists and historians. If DKIM upsets you, how do you get
| your head around disappearing messages?
| Alex3917 wrote:
| > 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 you shouldn't
| send it. The first national scandal involving email was
| Iran Contra in 1986. People should know by now not to put
| anything into an email that they wouldn't be comfortable
| with the entire world knowing. And while privacy is hugely
| important to individuals and essential for a healthy
| society, to me rotating DKIM keys feels like it's
| incentivizing people to use email incorrectly.
| harikb wrote:
| Then why don't we design such a system first with a
| higher level of guarantee first and inform users that
| this the goal.
| Alex3917 wrote:
| We did, it's called email. The phrase "like a postcard"
| is how email has been described for decades -- by our
| school systems and the media when educating the general
| public, in corporate training, and in the court system.
| gowld wrote:
| This is an absurd claim.
|
| There is not a popular email system in existence that
| says
|
| "To: myfriend@mailserver.com CC: Everyone [NON-EDITABLE]"
|
| Quite the opposite is true. Gmail, for example, says
| "Google.com Mail protects your message during delivery As
| you add people to this message, this icon will let you
| know your message is secure."
| sbierwagen wrote:
| >how do you get your head around disappearing messages?
|
| I get my head around them by thinking they are bad? As in,
| not good. An undesirable property.
| tptacek wrote:
| I mean, I guess you'd have to think that, to think that
| ensuring deniable emails is "shameful", as this thread
| suggests. I just wonder what the boundary of that
| thinking is. Message encryption also impedes activists!
| microtherion wrote:
| That just proves that he did send the mails he published. But
| since he did not put the mails on a block chain, we'll never
| know whether he was e.g. exchanging steamy e-mails with Grace
| Hopper or arranging weed deals with E.W. Dijkstra (or vice
| versa) on the side and decided to omit them from his
| published correspondence >:-)
| jamie_ca wrote:
| 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?
| Alex3917 wrote:
| > Do you mistrust the unsigned emails from 10+ years ago
| because they were sent prior to DKIM?
|
| 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.
| codebolt wrote:
| Might have something to do with this:
|
| https://www.washingtonexaminer.com/opinion/the-hunter-biden-...
| bjornedstrom wrote:
| As a security professional I 100% agree with the author.
|
| The 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.
| megous wrote:
| Can't you just set up your mailserver so that it drops all the
| crypto headers (DKIM-Signature, ...) after verifying them and
| storing the result in Authentication-Results? Only your server's
| Authentication-Results header is really relevant to spam
| filtering, anyway.
|
| Unless you're debugging something those headers seem irrelevant
| anyway, and they bloat the messages very much. (often times they
| are 3-4x the size of actual email)
| some_furry wrote:
| > Can't you just set up your mailserver so that it drops all
| the crypto headers (DKIM-Signature, ...) after verifying them
| and storing the result in Authentication-Results?
|
| Matthew Green's ask isn't about protecting users that are tech-
| savvy enough to _just_ set up their own mailserver and
| configure it a special way.
|
| It's about protecting the billions of users that aren't.
| adrianmonk wrote:
| Gmail (and other email providers) could also protect these
| billions by making the header-stripping change at the server
| level for everyone.
|
| After all, Green is proposing for them to change their
| servers anyway, so either way it requires some kind of server
| change.
|
| The advantage of Green's approach is it gets results quickly
| because with one change they can protect a lot of emails.
| But, while quick results are nice, is this problem really so
| urgent that only the fastest solution should be considered?
|
| Another difference is the set of users who are protected. If
| you rotate DKIM keys, you _protect Gmail users against non-
| repudiation risks_ because their outgoing emails become more
| deniable. But if you strip headers from Gmail users '
| inboxes, you _protect Gmail users against hacking_ , because
| now hacking a Gmail account gets you less-valuable data.
|
| Also, publishing old DKIM secret keys will require some
| distribution method. Where do you actually put them? For a
| given email provider, where do you go look to find them? It's
| a solvable problem but it's one that doesn't exist with the
| header-stripping approach.
| hamburglar wrote:
| Yes, the call isn't for GMail to kill non-repudiation
| protections on mail they _receive_ (and was signed by
| others), it 's to kill it on emails they've _signed_ and
| thus are sitting on someone else 's server.
| TheCoelacanth wrote:
| That only protects the people who send email to you. It does
| nothing to protect you.
| megous wrote:
| Hmm. Right. So the only option on sender side is to not use
| DKIM at all, or rotate the keys as suggested.
| hammock wrote:
| Perversely, this solution could result in MORE emails being
| hacked MORE OFTEN. Allow me to explain.
|
| If a hacker were to retrieve some emails before the DKIM key was
| made public, they could then sign their hacked emails with their
| own timestamped signature, proving that they are in fact
| authentic (since the signed timestamp shows that they were
| retrieved before the DKIM key was released).
|
| Therefore, by rotating the DKIM keys "every few weeks" you are
| giving the would-be hackers a deadline to retrieve the target
| emails - a few weeks - which could lead to hackers preemptively
| hacking as many _possibly useful_ accounts as possible (not just
| the ones they know they want at a given moment), every few weeks.
|
| (The merits of OP's argument notwithstanding)
| hyperpape wrote:
| 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?
| adrianmonk wrote:
| 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.
| hyperpape wrote:
| 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).
| lolc wrote:
| If crackers could justify the resources, they would already now
| be doing more cracking. It's not like they can just scale their
| operations ten times all else staying equal. The proposed
| change in key rotation and publication makes fresh mails only
| more valuable relative to old messages, not more valuable in
| general.
|
| If we're looking at cracking-activities from an economic point
| of view, publishing DKIM keys makes the cracking harder:
|
| 1. More accounts need to be cracked fast
|
| 2. Timestamped signatures must be published in a timely way
|
| 3. Results must be stored until they become useful
|
| These things not only increase cracking expenses, they also
| increase the threat of detection.
| 1vuio0pswjnm7 wrote:
| Two questions:
|
| Have there ever been any Gmail design decisions where users were
| consulted first?
|
| I was recenty informed by another HN commenter that "99% of
| users" are "not qualified have opinions" on something like the
| new MacOS behaviour,[FN1] or in this case Gmail's behaviour. If
| this is true, can/should "99%" of users be given the choice not
| to use DKIM when they are "not qualified" to have an opinion on
| DKIM?
|
| 1. https://news.ycombinator.com/item?id=25100342
| blibble wrote:
| > Google could launch the process right now by releasing its
| ancient 2016-era private keys. Since the secrecy of these serves
| literally no security purpose at this point, except for allowing
| third parties to verify email leaks, there's no case for keeping
| these values secret at all.
|
| I've used Google's DKIM signatures to timestamp call recordings
| for years by putting a sha256 of the attached recording in the
| subject, so "literally no security purpose" isn't true!
|
| (though I should probably go through and timestamp those
| signatures right now them using another method, just in case this
| guy's idea gains any traction)
| thinkharderdev wrote:
| If you have a specific use case where you need non-repudiation
| then there are numerous other tools you can accomplish that
| with. I think the author is arguing that it shouldn't be on by
| default.
| taldo wrote:
| The answer to every problem: blockchain!
| nisuni wrote:
| DKIM might have non-repudiation as unintended side effect, but I
| am totally fine with it!
| tarkin2 wrote:
| I'm torn.
|
| But someone could threaten to speak to your insurer about a
| medical condition mentioned in an email.
| yobert wrote:
| To me this indicates a failure in the healthcare system--- a
| much more important problem to fix.
| egberts1 wrote:
| One could always add a "CC:" before the DKIM-start "From:" and
| still pass DKIM, no?
| jmnicolas wrote:
| I treat emails as postcards: I assume anybody can read them.
| gojomo wrote:
| We've backed into a particular default, more via path-
| dependencies than conscious choice, that:
|
| * emails between major email providers have this lingering semi-
| authenticity indicator that authors didn't explicitly choose
|
| * to the extent the providers keep their DKIM keys non-public,
| only those providers (or those who exfiltrate such keys) can
| forge old emails
|
| Both of these have problems if considered from 1st principles:
|
| * Users should be able to control if they're creating non-
| repudiable messages.
|
| * No one, not even Google, should have the power to create
| authentic-seeming forgeries.
|
| This article's author, Matthew Green, suggests rapid expiration &
| disclosure of DKIM keys to narrow the window of time the user is
| subject to a non-repudiation they didn't choose. (Green here only
| specifically requests disclosure of years-old keys to invalidate
| older message archives, but conceivably a rigorous expiration-
| and-disclosure schedule could be chosen to limit the risk to
| weeks or days.)
|
| And via public disclosure, Green intends to indirectly address
| the risk of privileged parties forging emails, by giving
| _everyone_ the same power-to-forge older emails - so no
| particular forgery can be too convincing.
|
| But these new defaults are nearly as ad-hoc - reactive without
| conscious design - as the DKIM problem they purport to solve.
|
| Many would prefer that their emails, or at least some of them, be
| non-repudiable for a while or indefinitely. Many recipients would
| like to maintain their own private authenticity records - which
| as Green notes, can be bootstrapped into existence (even with
| rapid-expiring DKIM keys) by secure-timestamping messages &
| current DKIM keys at the time they're received.
|
| (To the extent Google & other providers have internally-trusted
| tamper-proof logs, they may already have de facto secure
| timestamping happening on all inbound/outbound email. Thus any
| amount of DKIM key fouling wouldn't stop _their_ unique internal
| ability to authenticate older messages, for their own forensic or
| political purposes.)
|
| I'd prefer users be given some visibility into, and choice over,
| how much durable authentication is added to their email messages
| - before adopting either Green's quick fix (publish old keys
| ASAP), or defaulting all users to his potential longer-term
| solution of explicitly "non-attributable email" (per his KeyForge
| paper or other schemes).
| advisedwang wrote:
| If Google did rotate the keys, it's quite likely some
| enterprising people would log observed keys. With access to a log
| of keys (that you don't believe has been tampered with) then
| rotating keys doesn't prevent non-repudation.
|
| An alternative would be for email servers to strip the DKIM
| headers on inbound emails after recording that the email was
| validated. The email stored at rest then no longer provides non-
| repudation. Nothing is stopping you doing this today.
| arkadiyt wrote:
| > rotating keys doesn't prevent non-repudation
|
| That's why he says Google also needs to publish the private
| keys.
| [deleted]
| kennywinker wrote:
| I'm not a fan of offloading that trust onto my email host. Not
| that I validate dkim headers, but the fact that I have access
| to them keeps my email host honest.
| bawolff wrote:
| I don't see non repudation as that bad a thing. Are people any
| less likely to be blackmailed due to technical deniability of
| email contents? I feel that for most, that wouldn't matter.
| busterarm wrote:
| No, this post has absolutely nothing to do with Hunter Biden's
| emails having valid Google DKIM.
|
| Nothing at all.
| gnarbarian wrote:
| What would that accomplish though for either side?
|
| Have the signatures been validated? You don't need the private
| key to do so.
|
| Assuming the keys are valid; either the emails are real, or the
| keys were stolen and the emails forged.
|
| I suppose if keys are released it gives plausible deniability
| for any leaked emails that occur AFTER the key release. So I
| can see why people sending incriminating emails would support
| this.
| [deleted]
| arkadiyt wrote:
| Interesting/educational read but I'm still not convinced that
| this unintended side effect is a bad thing - it seems like a
| desirable property to have authenticated emails. Matt argues this
| might lead to regular folks (as opposed to politicians) getting
| blackmailed, but:
|
| 1) it seems unlikely this cryptographic proof is needed (he
| acknowledges this criticism in the post), and
|
| 2) what seems more likely to me is that politicians would
| intentionally _not_ opt in to any alternate solution and use that
| deniability for their own advantage. (Also as an alternate he
| proposes GPG, which I know Matt knows is laughable).
| n0nc3 wrote:
| Put the company you work for in your threat model, and this
| becomes relevant to you.
|
| The corporate world is mired in zero-sum competition, and some
| of your colleagues are willing to do things that will shock and
| appall you if it increases their chance of "winning".
|
| Try working in defense, finance, or security as a closet
| anarchist. Have a few Chomsky books in your Amazon purchase
| history? Good luck climbing the Amazon corporate ladder.
| CodesInChaos wrote:
| You can authenticate messages in a way that only the recipient
| can verify (Diffie-Hellman plus MAC).
| arkadiyt wrote:
| If you had access to a public key for every email address
| then why stop at authentication - you could encrypt all email
| on the web. But we don't, so we can't.
| CodesInChaos wrote:
| Authentication in this context doesn't need to be end-to-
| end. Instead of a custom protocol, we could probably just
| use SSL client certificates authenticating the sending
| domain to achieve the same effect.
| tomrod wrote:
| Maybe we should.
| busterarm wrote:
| You might want to validate your emails more than a few months
| out.
|
| Regardless of if your emails are valid or not, blackmail is
| still a crime. Not being able to have your emails validated
| doesn't protect you from blackmail. The power of blackmail is
| often in the social cost of the accusation itself. The thing
| that protects you from blackmail is not getting involved in
| things you can be blackmailed for.
|
| This is like saying don't lock your doors so that nobody can
| break and enter into your house.
| vorpalhex wrote:
| > The thing that protects you from blackmail is not getting
| involved in things you can be blackmailed for.
|
| This is incorrect, because the things that someone can be
| blackmailed for is not the same as the set of immoral or
| unethical acts. You can be blackmailed for being gay, or for
| having a serious medical condition that's undisclosed.
| Neither of those situations is a "well just don't do that"
| kind of thing.
|
| The defense against blackmail is to make blackmail difficult
| (eg release DKIM keys), severely punish people who engage in
| blackmail, and guard your secrets effectively.
|
| > This is like saying don't lock your doors so that nobody
| can break and enter into your house.
|
| This is like saying the latch on your fence is a security
| mechanism. Nobody intended that fence latch to keep your safe
| or secure and hiding behind it won't make you safer. Rip away
| the false pretense.
| busterarm wrote:
| Nobody is telling you to not be gay. If you being gay is a
| secret, then don't send that secret over _plain fucking
| text email_.
|
| Do you send your social security number to people in
| emails?
|
| Email has never been privileged communication and the
| problem isn't one of validation but one of not
| understanding one's level of privacy and risk. It uses
| relays without end-to-end encryption and there's no
| guarantee that what you sent is not totally out in the
| open.
| lxgr wrote:
| If a global infrastructure provider can, without
| downside, offer non-repudiability - why shouldn't they?
|
| Not everyone is tech savvy. Not everyone understands
| encryption. Not everyone makes rational choices all the
| time.
|
| Does that mean everybody should suffer the consequences
| of an arguably unintentional side effect of the technical
| implementation of DKIM?
| RyanCavanaugh wrote:
| This is every bit as much about email you _receive_ as
| email you _send_ , and you are not in control of email
| you receive.
|
| If your doctor slips up and emails you about your AZT
| prescription, it doesn't matter how careful you were
| about not disclosing your HIV status over email you sent.
| busterarm wrote:
| yes, my point is that we should make sure that _no one_
| is stupid enough to secrets in plain text.
|
| with criminal repercussions
|
| Or better: don't use email and don't give an email
| address out to people who hold your secrets.
| ars wrote:
| Blackmail existed long before DKIM was a thing.
|
| Being able to say "no I didn't say that" is far more
| powerful than the reverse because the reverse has existed
| for thousands of years.
|
| But being able to definitively prove that you did not say
| something is brand new and very powerful.
| michaelmrose wrote:
| Doesn't DKIM make it harder to blackmail or destroy someone
| with fake emails because they can show their lack of
| authenticity?
|
| Shouldn't we privilege protecting people from lies vs
| protecting people from the truth?
| vorpalhex wrote:
| No because it's not on us to make moral distinctions
| between someone who is gay and doesn't want to make that
| information public, and someone who isn't gay and is
| being falsly blackmailed.
|
| Publishing the DKIM keys makes both cases harder because
| you no longer have authenticity claims. Neither claim has
| authenticity value and instead is just a "their word
| versus yours" situation.
|
| Humans are terrible moral adjudicators, and acting off of
| universals leads to repugnant ends. The truth can
| absolutely do terrible damage and still be the truth, but
| being the truth doesn't remove value from privacy. Put
| another way - would it be moral to publish your full
| medical records in the public? After all, they are the
| truth...
| michaelmrose wrote:
| It is on us to make moral choices. You are suggesting we
| do so by making email repudiatable in order to protect a
| hypothetical person from being outed via stolen email
| verified with dkim.
|
| So far as I can tell this has never happened in history
| and logically neither blackmail nor public harm via
| exposure of sexual orientation particularly requires dkim
| verification.
|
| It looks like you are asking us to give up DKIM
| verification which could and has aided us to verify
| politicians leaked emails in search of a purely
| hypothetical gain that may never materialize by
| suggesting that we both must and must not make moral
| determinations.
| baobabKoodaa wrote:
| When an angry mob goes after suspected homosexuals, do
| you think they stop to authenticate DKIM signatures of
| emails? I'll give you a hint: no. In fact, it's hard to
| imagine any scenario where anybody goes through the
| trouble of authenticating e-mails of a "normal person"
| who is persecuted of something other than crimes.
| lxgr wrote:
| Homosexuality is considered a crime in quite a few
| countries.
| busterarm wrote:
| Well, then if you live in one of those countries or plan
| on traveling through them, you're probably at risk if
| you're an open homosexual.
|
| You wouldn't tape your key to your front door. Don't send
| secret information out in plain text.
| baobabKoodaa wrote:
| > Shouldn't we privilege protecting people from lies vs
| protecting people from the truth?
|
| Indeed! I couldn't have put it better myself.
| mthoms wrote:
| Sounds like the "If you've got nothing to hide, you've got
| nothing to fear" argument. Not very compelling.
|
| https://en.wikipedia.org/wiki/Nothing_to_hide_argument
| busterarm wrote:
| See response here:
| https://news.ycombinator.com/item?id=25114692
| mthoms wrote:
| Okay, but what about a topic that is legal and acceptable
| in today's society but not in the society 20, 30 or 40
| years down the line? What if being gay becomes socially
| unacceptable again? Or supporting the second amendment?
| Or [literally anything]?
|
| The problem is that what is socially and legally
| acceptable _changes over time_. Just 30 years ago, the
| standard for social acceptable commentary was wildly
| different in the areas of gender identity, sexuality, and
| race for instance.
| busterarm wrote:
| Yes, you should absolutely think about everything that
| you commit to public record.
|
| Yes, you might be totally fine now. You might be hanging
| out and get photographed with this creepy billionaire
| named Jeffrey Epstein who is just another creepy
| billionaire at your creepy billionaire parties. Then 20
| years from now we find out he's running pedophile island
| and people start looking into your associations.
|
| We are not teaching people to be cautious about their
| public data and in fact there's an entire industry out
| there encouraging everyone to detail their whole lives in
| public record.
|
| Get off of social media _today_. Yes, it's probably too
| late. The other option is to be such a big celebrity that
| your entire life is public and you have the defense of
| scrutiny.
|
| Side note: Somebody from my high school class is a famous
| criminal. I regularly receive requests for interviews on
| the basis of that association alone despite having
| nothing to do with the person for decades.
| mthoms wrote:
| Using the billionaire pedophile example is a disgusting
| trick. You're trying to set me up for appearing to
| support that.
|
| Why not use more neutral examples? Like being gay or
| supporting certain political causes? What if those later
| become controversial or illegal? What then?
|
| Do you want to live in a world where you have to guard
| everything you say in semi-private conversations, just in
| case it one day becomes controversial? That sounds like
| an oppressive nightmare.
|
| The social media argument is tangential but I do agree
| with you there.
| busterarm wrote:
| I'm not setting you up as supporting anything.
|
| I'm illustrating the severity of the public record.
| mthoms wrote:
| >I'm illustrating the severity of the identifiable public
| record.
|
| This is an argument _in favor_ of emails being non-
| verifiable, so now I 'm confused.
|
| Previously you seem to be supporting the idea that email
| _should be_ verifiable. Now you seem to be arguing the
| opposite. Everything you wrote above correlates with the
| opinions I 've expressed so far.
|
| You also wrote:
|
| > If you live in a [country where homosexuality is
| illegal] and secretly a homosexual, do not send emails
| indicating that you're a homosexual.
|
| As if that's an acceptable state of affairs and a
| reasonable compromise for the purpose of catching the
| occasional bad actor. It isn't.
| Paul-ish wrote:
| The piece seems to be arguing from a general principle. Non-
| repudiation is a feature of most secure messaging applications
| and it is a feature that should be introduced to GMail. This
| argument doesn't fully address how technologies are actually used
| today.
|
| As far as I can tell, people who need non-repudiation are already
| using apps that have non-repudiation (eg Signal), because they
| know they are in a vulnerable position. The people who need non-
| repudiation already have it. So far we have seen DKIM
| authentication used against individuals in positions of power.
| With things as they are, cryptography is leveling the playing
| field by empowering the vulnerable while holding those in power
| responsible. If this situation or balance were to change perhaps
| it would make sense to rethink DKIM non-repudiation. I understand
| this is an opinionated/political take on cryptography that not
| everyone would share.
| lxgr wrote:
| > The people who need non-repudiation already have it.
|
| Can you really not think of a scenario where non-repudiation
| could be important even to people "not in power"?
| punnerud wrote:
| DKIM secrets should also be added to GDPR-dump/export, and
| releasing keys in the same way after a while. Would make imports
| into other services possible, by trusting the legitimacy of
| export.
| jedberg wrote:
| It's interesting that he asks for this solution but not the more
| easy to implement solution to the other side of the problem
| (which you can do if you run your own server): remove the DKIM
| signatures upon delivery to your inbox. Google can just add in a
| tag in their database that says "this message was verified". Or
| at least make it an option for users if they want that ability.
|
| In the case of Podesta, the emails were stolen from his gmail
| account. If the headers weren't there, the messages would have
| been unverifiable.
| landryraccoon wrote:
| 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 that this feature has been used primarily
| by political actors working in a manner that many people find
| agreeable -- either because it suits a partisan preference, or
| because the people who got "caught" sort of deserved it.
|
| > But bad things happen to good people too. If you build a
| mechanism that incentivizes crime, sooner or later you will get
| crimed on.
|
| The author seems to be arguing that if after a certain point it
| becomes impossible to verify whether an email was genuine or not,
| that would somehow be a good thing.
|
| This reasoning seems harmful to me. It's incredible that the
| author treats this moral argument as self evident. Let me state
| my objections clearly.
|
| 1. The truthfulness and reliability of the historical record is
| important. The fact that politicians are protected from blackmail
| when they write incriminating emails is utterly insignificant by
| comparison. Is the principle being defended that protecting
| politicians from blackmail is stronger than a public interest in
| having a historical record?
|
| 2. Making historical emails impossible to authenticate after a
| certain period of time makes it more difficult to prosecute
| crimes. It helps criminals, the very thing the author claims to
| be trying to avoid. If a politician, or anyone for that matter,
| sends an incriminating email which is evidence of the intent to
| commit a crime, why on earth would you want to make it easier to
| cover your tracks?
|
| Seriously, can someone present a moral argument for why this
| should be adopted? It seems only harmful to me.
| woodruffw wrote:
| I'm not going to present a moral argument (what is a moral
| argument in this context?), only two direct rebuttals of your
| objections:
|
| 1. DKIM provides neither truthfulness nor objectivity. It's a
| signature mechanism used between mail servers to reduce spam.
| For implementation reasons, most DKIM users sign with RSA keys
| that are either _currently_ crackable or will be crackable in a
| matter of years. Consequently, "signed" emails that are leaked
| years after their alleged transmission provide a _false_ sense
| of non-repudiation.
|
| 2. Per 1, these emails are _already_ impossible to authenticate
| after a period of time. This just makes the expectation more
| explicit. More generally, however, this just isn 't a fruitful
| (or intended) application of DKIM: if the government wants to
| obtain evidence of a crime, they're going to subpoena the email
| provider and retrieve the originals. If the suspected criminal
| is sufficiently important, they'll use pointier methods. The
| outcomes of our criminal justice system _intentionally_ doesn
| 't hinge on the validity of a few DNS-published RSA keys.
| landryraccoon wrote:
| If right now DKIM doesn't provide truthfulness or
| objectivity, then the author's blackmail example already
| doesn't apply.
|
| DKIM signatures, by your argument, are useless in blackmail,
| since they don't verify the message. So why did the author
| resort to that as an example?
| woodruffw wrote:
| First: I don't think Matthew Green "resorted" to anything.
| I think he chose the blackmail example because it's easy to
| understand on a personal level: we all use repudiatable
| protocols in other contexts (like Signal), so why wouldn't
| we want it on our emails?
|
| Second: That's not how blackmail works. It's contingent on
| what the extorted party _thinks_ , not the cryptographic
| integrity of the blackmail material. That's why mass
| blackmail spam campaigns (that DKIM fails to prevent,
| ironically enough) are remarkably effective. Publishing
| DKIM secret keys after their expiry doesn't magically
| prevent blackmail; it just removes one more tool from the
| blackmailer's toolbelt for instilling fear in the target.
| detaro wrote:
| The problem is that it's not clear about it. It looks like
| it does quite a bit, and the counter-argument boils down to
| "someone could have cracked the secret key", which everyone
| always is told is the thing that is impossible. So you get
| plenty people believing and claiming DKIM can do that. This
| would be fixed by obviously breaking it.
| tptacek wrote:
| 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
| for giving OTR short shrift and thus ensured I'd always
| associate his name with OTR and thus, I'm sure to his delight,
| his name being dropped on this thread.
|
| I'd again like to point out how clear it is, the epistemic
| approach being taken in this thread. You can disagree with
| deniable messaging as a valid goal (it'd set you apart from
| cryptography engineers, but that's fine). But you can't be
| _appalled_ by it in 2020, because the idea is old enough to
| drink in a bar in Canada, and motivated at least two of the
| most famous protocols in all of cryptography.
|
| Instead, what people are doing here is skimming this post,
| digging no further, and then calling to mind their
| understanding of current events. Then, from that tiny thread of
| information and a bunch of axioms invented, I presume, in the
| span of just a minute or two, they're deriving an entire first-
| principles explanation of how messaging security is supposed to
| work.
|
| You can do that, but I think it's more than fair to point out
| that there are people that have dedicated their entire career
| to studying this subject and publishing on it, and if
| commenters are going to make it clear that they haven't even
| tried to engage with that material, it's unclear why they
| should be taken seriously.
|
| Also, Google should publish DKIM keys.
| landryraccoon wrote:
| 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?
| tptacek wrote:
| I don't know how fair this is but will just say that the
| first thought that jumps to my mind here is that being
| surprised at a cryptographer advocating for deniable
| messages is a little bit like being surprised at a medical
| researcher advocating for effective antibiotics. It
| probably never occurs to either of them to question the
| legitimacy of their moral stance.
| landryraccoon wrote:
| I certainly could be wrong. What's the case for
| repudiation? Is making blackmail harder really the
| cryptographer's mail argument for why repudiation is a
| benefit?
|
| I didn't see a more convincing argument in the blog post.
| If there is a technical reason why repudiation is
| beneficial, I would be grateful for an explanation.
| tptacek wrote:
| Read Goldberg, Brewer, and Borisov:
|
| https://otr.cypherpunks.ca/otr-wpes.pdf
| fhrow4484 wrote:
| > Let me state my objections clearly.
|
| > 1. The truthfulness and reliability of the historical record
| is important. [...]
|
| Everybody agrees here, but how does one gets to decide that
| Google, a private corporation, is the one to decide that a
| given email is an accurate historical email? An email provider
| is a defacto certificate authority? Are these dkim keys subject
| to the same standard of care as private keys that CAs manage?
|
| For your regular-person scenario, having a way for a 3rd party
| private company "certify" an email sent from another private
| company (example: your online order) may be good enough, but is
| it good enough in every scenario?
| shinigami wrote:
| 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?
| [deleted]
| some_furry wrote:
| > Seriously, can someone present a moral argument for why this
| should be adopted? It seems only harmful to me.
|
| Because this isn't just about _politicians_ , or holding
| politicians accountable. It affects the rest of us too!
|
| Instead, imagine what would happen if a hacker accessed the
| email of a closeted LGBTQIA+ person living in a country where
| being outed is practically a death sentence, and the DKIM
| signatures were sufficient proof of guilt.
| scarmig wrote:
| In the general case, repudiation is desired by users, and non-
| repudiation is needed in only very particular cases. Companies
| serving nontechnical users should make repudiation the default,
| because if given the choice most users would prefer it to be
| the default.
|
| In the particular case of Google releasing its DKIM keys, I
| think I would need more context. What kind of repudiation
| property do users expect when sending emails over GMail? Is
| non-repudiability currently used by users for legal or business
| purposes? Probably the way to do it would be to announce a
| particular date maybe a year into the future that the private
| keys would be released.
| 013a wrote:
| I think there's an angle to the plausible deniability that many
| people are missing.
|
| Email servers get hacked all the time, right? A disgusting
| amount. Its almost like security is really difficult; in fact,
| its difficult to secure both the emails _and the DKIM private
| keys_. They 're usually on the same server, after all.
|
| If a DKIM private key gets hacked, and the world relies on DKIM
| to provide non-repudiation in the verification of email leaks,
| then a hacker who obtains someone's DKIM private key could forge
| an email to contain any content they want, sign it with that
| private key, then leak that. The world says "its DKIM validated,
| Trump really did kill a litter of puppies twelve years ago",
| Trump tries to say "no, my email server was hacked, i never did
| that but they got my DKIM key" and who the hell would believe
| him? The headlines have already been written, and the argument
| against it is some crazy technical terminology a hundredth a
| percent of the population actually understands?
|
| Ok, well, maybe you should rotate DKIM keys. Not necessarily make
| the private portion public, but at least rotate them and totally
| destroy the old private keys. But, again, if an email server is
| misconfigured enough to leak data, then its likely the admin is
| incompetent enough to also not be rotating keys. Moreover,
| unauthorized access to a server could happen over a period of
| years, during which hackers collect the rotated DKIM private keys
| while letting the admins think they're being deleted correctly.
|
| The problem here isn't really DKIM; its the public's perception
| of what it was designed for. Technologists invented something,
| journalists discovered it, read a wikipedia article, and thought
| "woah we could use X for Y". So, I think it makes sense that we
| need a big name like Google to come out and say "Stop, this is
| not what this was designed for, it has major limitations in being
| used for that, and we're talking about real-world consequences
| like ruining potentially innocent peoples' lives."
| busterarm wrote:
| If everyone had a proper understanding of email and was not
| dumb enough to send out secrets via email, or to at least
| encrypt the content of those emails...then nobody would believe
| such a leak to be plausible.
|
| Sadly that's not the case.
| creeble wrote:
| 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 you 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.
| morpheuskafka wrote:
| It seems like this would also be useful for proving
| contracts/statements over email in business law. While it may not
| have been designed for this purpose (and there could still be
| claims that the sending account was hacked, unlike a personal GPG
| key which identifies the individual rather than the
| infrastructure), it seems to be a pretty good thing to have.
| Google234 wrote:
| I find it pretty funny that the author wrote this because they
| are salty that the leaked hunter Biden emails could be verified
| with DKIM
| edoceo wrote:
| This is false. The article pointed to DKIM being used for
| journalistic verification for multiple parties (persons and
| organizations) across the political spectrum. It's not salty or
| overtly political.
| whereshunter wrote:
| Their lack of addressing Hunter's emails says the most.
| epaulson wrote:
| This would break a cool indieweb "hack" with DKIM - webfistbump,
| which lets folks participate in webfinger even if their email
| provider doesn't support webfinger, like gmail:
|
| https://www.onebigfluke.com/2013/06/bootstrapping-webfinger-...
|
| (I suppose you could just re-opt into webfistbump every time your
| email provider is about to publish their DKIM key)
| upofadown wrote:
| This relies on the problematic approach to deniability of making
| forgeries possible.
|
| To make this work you need to claim a forgery when you know that
| no such forgery occurred. So you explicitly or implicitly have to
| accuse someone of a serious crime/offence they did not commit.
| Most people have a greater sense of honour than that. Those that
| don't would still have to fear getting caught.
|
| If someone actually does forge a message using the old private
| keys provided by Google then you would have to fight the
| assumption that you were using the system as it was designed.
| Everyone would just assume you said it and are now using the
| possibility of forgery to lie about having said it.
|
| You can always claim a forgery anyway should you decide to do
| that. Perhaps someone got access to Google's relatively poorly
| guarded DKIM private key. How would you know? You are probably
| not making a specific claim anyway.
| avianlyric wrote:
| There should be no need to make claims of forgery. The mere
| fact that an email can be forged will substantially reduce the
| likelihood of email being used, unless clear providence can be
| provided.
|
| At the moment that providence can be proved with DKIM. Remove
| DKIM and now bad actors need to prove that they actually broke
| into someone's emails and stole them. A much high bar to pass,
| especially as it may mean incriminating yourself of a crime.
|
| Emails become just as useful as find a pile of top secret
| papers on the floor. Unless you can prove the source of those
| papers everyone is going to ignore you.
| nevinera wrote:
| If you have nothing to hide, you have nothing to fear! Privacy
| schmivacy.
| nevinera wrote:
| I personally am absolutely confident that every email I sent
| during college and my adolescence would merely shine brighter
| light on the perfection of my soul. It sounds like the rest of
| you should probably have behaved better.
| hpoe wrote:
| So 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 it should be
| public knowledge.
|
| After all an efficient marketplace only is efficient if all
| actors have access to as much information as possible.
|
| EDIT: As a follow up, several people point out that it could
| happen to me or a family member, but this seems even further
| reason to have DKIM so that if someone attempts to blackmail me
| based on the contents of my email, checking the DKIM signature
| makes it even easier to disprove a bad blackmail attempt.
| mthoms wrote:
| The threat is not limited to politicians. Anyone (including you
| and your family members) could be blackmailed or otherwise
| publicly embarrassed.
| hashtagmarkup wrote:
| > The threat is not limited to politicians. Anyone (including
| you and your family members) could be blackmailed or
| otherwise publicly embarrassed.
|
| ... for what they actually did.
|
| You think the solution is allowing people to be blackmailed
| or otherwise publicly embarrassed for things they didn't do,
| while removing their ability to verify that they didn't do
| them?
| bee_rider wrote:
| People change over time, and normal human communications
| have a natural sunset as most people don't remember every
| conversation in exacting detail. It is worth at least
| considering the fact that we've signed up to have basically
| all our communications preserved and cryptographically
| signed in perpetuity. Most people using these services
| didn't fully weigh the options.
| blendergeek wrote:
| No. Once DKIM keys are published, one can simply deny all
| emails published "from their account". We currently have a
| way for an attacker to prove an email's origin years after
| the fact.
| hashtagmarkup wrote:
| Yes. We are saying the same thing.
| mschuster91 wrote:
| > ... for what they actually did.
|
| Being gay is not a crime, and yet people can be blackmailed
| with it. It is very easy to open yourself up to blackmail
| by perfectly legitimate activities.
| hashtagmarkup wrote:
| > Being gay is not a crime, and yet people can be
| blackmailed with it. It is very easy to open yourself up
| to blackmail by perfectly legitimate activities.
|
| Option 1: DKIM keys stay private... "That email was just
| a joke, I'm not really gay" Option 2: DKIM keys go
| public... "That email was just someone else's joke, I'm
| not really gay"
|
| Not really a difference, and with option 2 you can't
| prove you didn't send it (as far as you can prove someone
| didn't crack 2048 bit RSA and use that power to concern
| themselves with your sex life).
|
| Being able to prove a fascist dictator who was killing
| people for being gay, was secretly engaging in gay acts
| themselves, might help your cause of protecting gay
| people.
| morelisp wrote:
| > Being able to prove a fascist dictator who was killing
| people for being gay, was secretly engaging in gay acts
| themselves, might help your cause of protecting gay
| people.
|
| How?
| hashtagmarkup wrote:
| Because the DKIM keys were not made public, and a message
| sent from their account could be confirmed to be
| authentic.
|
| If the keys were public, they could claim forgery.
| Regardless they could claim their account was hacked, but
| they couldn't deny the message was sent from their
| account.
| morelisp wrote:
| I'm not asking how the technical mechanism proves the
| messages may be legitimate. I'm asking how you could use
| that knowledge in the specific situation you outlined to
| accomplish anything productive.
| ivanhoe wrote:
| True, there are things that might ruin someone's life
| even though there's nothing bad about them, but the list
| of actual crimes and bad things that people do is WAY
| longer, and being able to prove it is definitely
| useful...
| avianlyric wrote:
| The same argument can be used to build a police state.
| But I suspect that you're not in favour that either.
|
| We shouldn't be building technical systems that "trap"
| people, just because they might be doing something bad
| and might want to prove that one day.
|
| Additionally you're also ignoring the whole "people have
| the right, to not have their emails stolen" argument.
| DKIM signatures are only useful if the emails are stolen,
| are you trying to suggest that it's ok to steal emails
| from people if they're bad?
| daveFNbuck wrote:
| You're assuming no one has compromised the old keys. If
| that has happened, a blackmailer can forge old emails with
| proof of things you didn't do.
| mthoms wrote:
| You're misunderstanding how this works.
|
| You can't be blackmailed by someone who has no plausible
| evidence.
| beagle3 wrote:
| They don't have plausible evidence anyway. Gmail has had
| bugs before with SPF/DKIM and will have some again for
| sure.
|
| Some google employees have direct and indirect access to
| signing keys or writing emails. Not many, and they have
| good controls, but still many people with the ability to
| sign messages.
|
| Not to mention a Trojan infiltration or account takeover,
| of which thousands (if not millions) a day occur.
|
| The DKIM evidence is, for legal purposes, a good hint but
| far from proof.
| mthoms wrote:
| In the court of public opinion, the standard is not _"
| 100% proven beyond any reasonable doubt"_. Hence,
| blackmail can still be very effective if an accusation is
| highly plausible.
| beagle3 wrote:
| Yes, but it's not DKIM or not DKIM that will make it
| plausible in the court of public opinion.
| mthoms wrote:
| Current events prove otherwise. See Hunter Biden.
| hashtagmarkup wrote:
| You're misunderstanding how destruction of evidence
| works.
| mthoms wrote:
| 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.
| hashtagmarkup wrote:
| 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.
| mthoms wrote:
| This describes _all_ encrypted and short lived messages.
|
| Edit: Removed the word "literally" because it was
| incorrect and caused distraction from the actual
| argument.
| hashtagmarkup wrote:
| It doesn't at all. You're misunderstanding. Or, are you
| using the word "literally" in the modern sense of "not
| literally"?
| mthoms wrote:
| Are you just nitpicking my choice of words or are you
| going to explain how auto-disappearing messages aren't
| potentially destroying evidence in the exact same way
| you've described?
|
| As for for encrypted messaging, yes it is not the same as
| "literally" destroying evidence. But it is _hiding_
| evidence.
|
| The end result is the same in the context of the claims
| you previously made. That is: justice is potentially
| being subverted.
| whimsicalism wrote:
| I propose gouging out everyone's eyes, that way they can't
| see you do anything potentially embarrassing - thus making
| blackmail harder.
| hyperpape wrote:
| This is a helpful comment because not having DKIM is in the
| same range of bad outcomes as having your eyes gouged out.
| woodruffw wrote:
| > So 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.
|
| 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?
| beagle3 wrote:
| Well, by 2030 the non-repudiation will be considered lost if
| that's the case. Maybe even 2027. But today, in 2020, a
| verified DKIM is strong indication about the identity of the
| writer, or that the keys weren't safely stored.
| woodruffw wrote:
| > Maybe even 2027. But today, in 2020, a verified DKIM is
| strong indication about the identity of the writer, or that
| the keys weren't safely stored.
|
| Except that we're talking about leaks of emails that date
| back by years: the earliest Podesta emails are from 2010,
| back when Google was using 512-bit (!) keys for DKIM. Those
| were leaked in 2016, at which point _1024-bit_ keys were
| already considered crackable by a motivated attacker.
|
| This isn't to say that those emails were _faked_ , only
| that "an email written in 2020 that's verifiable in 2020"
| is not the target of interest.
| beagle3 wrote:
| ..... so? That means in 2016, the DKIM was already
| deniable. And it made no difference whatsoever.
|
| The DKIM signature is proof only that whoever signed the
| email possessed the key, nothing more, nothing less.
| This, in turn, is a suggestion about the identity of the
| signer and possibly the author - but not proof.
|
| Did DKIM change anything about the podesta emails? Or
| were they basically acknowledged as authentic regardless,
| and had a lot of other verifyable info in them?
| woodruffw wrote:
| > ..... 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 acknowledged as authentic regardless,
| and had a lot of other verifyable info in them?
|
| That's hard to say, but it's also not the point. The
| point with being able to crack the key is that a
| motivated party could intersperse _false_ information
| with otherwise verifiable information. And, well, what 's
| a conspiracy theorist to do? Only believe the non-juicy
| parts?
| beagle3 wrote:
| 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 to
| believe.
| woodruffw wrote:
| 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.
| blendergeek wrote:
| > that so people can't use email to blackmail politicians?
|
| He mentions the politicians because those were high profile
| cases. This could be used against anybody, not just
| politicians.
|
| > It seems to me that especially when an elected official has
| something they don't want others to know about that it should
| be public knowledge.
|
| Is this true of everybody else as well? Should anybody be able
| to deny an email they sent in the past? If so, we have to take
| this step.
| ivanhoe wrote:
| Other than whistleblowers and activists fighting the
| dictatorships (and they can work-around this), what is the
| case where not being able to prove who sent the email would
| be a good thing?
| mthoms wrote:
| -- Example --
|
| Dear Ivanhoe,
|
| I regret to inform you that your HIV test came back
| positive. Please contact my office at your earliest
| convenience to arrange a follow up.
|
| Sincerely, Your doctor
| santraginean wrote:
| No doctor should be writing that email in the first
| place; it would be an example of such a flagrantly
| negligent treatment of PHI that cryptographic signatures
| and reputability are kind of irrelevant.
| mthoms wrote:
| Email is used outside of countries with these kinds of
| protections. For example, I know someone who had an STI
| test in Thailand and the results did indeed come via
| email.
|
| Even if this example is imperfect, it's not impossible to
| imagine a scenario where some type of compromising
| information is sent to you.
| bee_rider wrote:
| Toward the end of the blog post, the author points out that
| while it often is nice to have the ability to authenticate
| who sent an email, nobody asked for this feature to be
| enabled by default on all their communications. It seems
| like a matter of preference, and it isn't clear that people
| thought about it at all.
|
| People change over time and normal human communications
| have a natural sunset built in as people forget exactly who
| said what.
| thinkharderdev wrote:
| It could (at least according to the author) reduce the
| incentive to steal people's emails for blackmail purpose to
| begin with. The target of blackmail can simply deny they
| are authentic and it would be extremely hard for the
| blackmailer to provide evidence of their authenticity
| without revealing their own identity.
| LinuxBender wrote:
| I am not a lawyer, but I do not believe that DKIM provides
| repudiation specific to an individual. DKIM provides evidence
| that email originated on an email provider. The users neither
| own nor control the server and user accounts get compromised
| all the time as well as fake accounts created all the time.
| Google battles this daily. DKIM might be one piece of
| information, used in combination with a client IP address and
| some method of proving who was at that client IP address at the
| time, but I do not believe that DKIM could stand on its own.
|
| For example, I have servers that DKIM sign emails. If a person
| uses my servers to send a death threat, the FBI is going to
| want web access logs and smtp logs.
| beagle3 wrote:
| It is even weaker than that. DKIM keys themselves can be
| stolen - most servers don't store them in HSMs (and HSMs are
| also not infallible).
|
| Or factored - Debian had a bug 12 years ago that caused weak
| SSH keys, a similar thing could happen to DKIM key generation
| (or has happened, but not yet discovered).
|
| Some study showed many RSA keys in the wild had a common
| factor. A weakness of this family might be discovered with
| DKIM keys.
|
| It is supporting circumstantial evidence, not proof of
| identity.
| mthoms wrote:
| Correct me if I'm wrong but elsewhere you to claim to be a
| conservative who has at least some mistrust in the recent
| election results. This seems like a paradox. Do you trust the
| government and its systems or not? Because the _" I've got
| nothing to hide"_ [0] argument doesn't work if you recognize
| that governments can and do go bad. Once that happens, they can
| retroactively change what is acceptable thought.
|
| https://en.wikipedia.org/wiki/Nothing_to_hide_argument
|
| Edit: Already at -1 votes with no explanation. To be clear I
| don't want to bring the election/politics into this. I only
| want to point out that "I've got nothing to hide" is a strange
| argument if you explicitly distrust the democratic systems in
| place around you.
| feanaro wrote:
| A _good_ blackmail attempt could then be devastating for you,
| on the other hand.
| 013a wrote:
| > As a follow up, several people point out that it could happen
| to me or a family member, but this seems even further reason to
| have DKIM so that if someone attempts to blackmail me based on
| the contents of my email, checking the DKIM signature makes it
| even easier to disprove a bad blackmail attempt.
|
| I think his point is that the DKIM signatures could be used to
| verify that you did, in fact, send something worth being
| blackmailed over, rather than having the plausable deniability
| of saying that your DKIM private key from that period is
| already public and thus could be forged.
|
| Which, to me, sounds similar to the classic XKCD
| "Theoretically, I use 2048bit RSA encryption and the hackers
| can't get my data. In Reality, they just beat me with a hammer
| until I give up the password." Maybe a public DKIM argument
| would hold up in court, but if we're just talking reputation
| blackmail among family and friends, it aint it chief.
| RcouF1uZ4gsC wrote:
| One thing that Google publishing their DKIM rotated keys is take
| fake news to a new level.
|
| Basically anybody could use those signing keys to fake email from
| a politician or celebrity. Imagine the headlines "Celebrity X
| account hacked, here are the emails, cryptographically verified
| by Google"
|
| Of course, informed people will know that anybody could have
| faked them, but I would guess normal people would be fooled. In
| addition, there is no way to say the emails are definitely fake.
| At least now, we can tell between actual leaked emails and fake
| emails.
| woodruffw wrote:
| > Of course, informed people will know that anybody could have
| faked them, but I would guess normal people would be fooled. In
| addition, there is no way to say the emails are definitely
| fake. At least now, we can tell between actual leaked emails
| and fake emails.
|
| No, you can't. Google used to use 512- and 1024-bit RSA keys
| for DKIM signatures, both of which are comfortably within the
| means of small-to-medium-sized nation states. They currently
| use 2048-bit keys, which will probably be crackable within the
| next decade.
|
| DKIM is providing a _false_ sense of non-repudiation here, one
| that it was never designed (much less correctly implemented) to
| provide.
| devit wrote:
| This seems like a feature, not a bug.
| mattbeckman wrote:
| As we head into the post-truth era, we already know videos are
| going to become far less trusted due to deep fake tech. Finding
| grains of truth through cryptography, like DKIM, is so refreshing
| that it hurts to think some people want to cripple it.
|
| The Hunter Biden email is a good example.
|
| I initially thought it was a garbage tabloid drop, but once I
| read Rob Graham's analysis, it felt very refreshing to have a
| real nugget of truth based on math. While the context of that
| content is up for debate, the truth was essentially undeniable
| (unless you subscribe to the 2016 private key being stolen).
|
| We need nuggets of truth.
| davewritescode wrote:
| The Hunter Biden email is a terrible example. It's very likely
| that what's been found on "Hunter Biden's" laptop is just
| hacked material which has been stuffed on a laptop to disguise
| the original source of the breach. In this case the DKIM
| signatures are being used to lend credibility to the story that
| the laptop was mysteriously left in repair shop, never to be
| reclaimed.
|
| DKIM is not meant to validate conversations, it's meant to
| validate single messages for the purposes of spam prevention.
| Just because I can cryptographically validate selectively
| chosen messages from someone's mailbox, I don't have any proof
| that the conversation happened as presented.
|
| There's a good reason why eliminating non-repudiation has been
| a goal of messaging protocols since OTR in 2004.
| [deleted]
| rabuse wrote:
| It's not farfetched to believe a crack-addicted wealthy
| individual who seemed to live a very "promiscuous" lifestyle,
| would have forgotten some cheap laptop at a repair shop.
| These people are humans, at the end of the day.
| buraktamturk wrote:
| Hey 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 especially
| verifies a crime - Turkish Airlines Nigeria Weapon transfer as it
| marks the event as "Government Secret"; The evidence that they
| talk on this e-mail involves a call where the ministers talk "I
| don't know if they will use it to kill Muslims or Christians".
|
| That specific e-mail does not have DKIM signature (maybe because
| it was sent his own gmail address? or to an gmail address in
| general?).
|
| I am aware that even if they publish the DKIM secrets, these
| e-mail will not lose any value since these e-mails was posted
| before the secrets.
|
| But I think using e-mails as evidence should be a thing in
| general. As you could receive them to your personal e-mail server
| and want to authenticate and use it on a court, even years after.
| If they publish the keys, it would not be possible as you could
| be the one who forged the e-mail as it were received from
| somebody else and has been put to your IMAP server manually.
| yholio wrote:
| In reality, that would throw forgery of such evidence in the
| hands of regular people, as opposed to those politically
| connected, the secret services, and nation-state hacker squads.
| While I sympathize with your political plight, I don't really
| understand why you would think that is a good thing in general.
| For all intents and purposes, it seems even worse, leaving the
| ability to weaponize public opinion in the hands of those who
| should most fear it.
| buraktamturk wrote:
| Except if you are the actual victim of these e-mails and the
| politicans who control 95% of the media are able to trick
| people either making them belive it was fake or it had
| "national interests" and they did it because of "country".
|
| At least these e-mails are believed to be true in other
| countries. So does Authenticity of thes e-mails can easily
| help you when you seek asylum in country from a country where
| they declared you as a terrorist - internationally.
| nullc wrote:
| Meanwhile, the IETF is speccing more messaging protocols with
| non-repudiation and HN users seem to be cheering that shortcoming
| along: https://news.ycombinator.com/item?id=25100316
|
| I think it's kind of unfortunate that there are many people that
| suddenly care when its powerful people or their families that are
| getting caught out by DKIM, these aren't the people who need
| protection from it the most. No one would even care if the Hunter
| Biden related emails passed DKIM except for the widespread
| allegation that they were fake, and no one still cares because
| conversation about them passing DKIM is widely suppressed
| (including on HN, unfortunately, where a post about it was
| immediately flagged). Oh well, I suppose it's like when the ACLU
| used to defend awful speech for the sake of defending free speech
| because those were the cases available which could make an
| impact.
|
| Unfortunately publishing DKIM secret keys only goes so far
| towards avoiding accidental non-repudiation: Recipients can
| cryptographically timestamp the signatures before the keys are
| published. ... and doing so already makes sense independent of
| DKIM. In fact, one of the ways that the public was able to prove
| that the outdated google DKIM key was a real key was that we were
| able to find cryptographically timestampped google signed emails
| from back when that key was still in use.
|
| Better than key publication is to avoid having a non-
| repudiateable stamp to begin with. This is much easier in the
| context of end-to-end two-party interactive protocols, but I
| believe is still possible for multiparty protocols.
|
| The analog for DKIM wouldn't work so well unfortunately, because
| DKIM isn't end to end. E.g. DKIM could be changed so that the
| signature demonstrated that either the sending server or the
| recipient server signed the message-- this would be just as good
| for anti-spam, but really wouldn't improve the non-repudiation in
| most cases. Contrast that with applying the same approach to end-
| to-end messaging, where it gives you pretty strong non-
| repudiation.
| newacct583 wrote:
| > No one would even care if the Hunter Biden related emails
| passed DKIM except for the widespread allegation that they were
| fake, and no one still cares because conversation about them
| passing DKIM is widely suppressed (including on HN,
| unfortunately, where a post about it was immediately flagged).
|
| Uh... no RFC822 headers from the Hunter Biden emails were ever
| released, certainly none with a passing DKIM signature. I read
| that Post article with a microscope. This never happened.
|
| And in fact, the transparent truth that these appeared to LACK
| the trivially producible authentication layer is one of the big
| reasons that the more right-leaning entities among the tech
| community stayed far away from this subject.
| drewbug wrote:
| https://github.com/robertdavidgraham/hunter-
| dkim/blob/main/M...
| newacct583 wrote:
| Interesting, thanks. Odd that this data was never part of
| the published record from the post, and that Graham's
| source is apparently secret? Curious what you make of that?
| If the Post had it, they'd surely have released it. I guess
| it's sort of academic at this point, but it does point to a
| few different actors pushing this story in different
| directions.
| nullc wrote:
| > If the Post had it, they'd surely have released it.
|
| It's extremely rare for journalist in traditional media
| to publish email headers, even when people are accusing
| messages of being inauthentic and the DKIM would go a
| long way towards certifying them and when people are
| begging for them. I think I'm aware of only one other
| instance.
|
| From the perspective of protecting sources it's probably
| good advice to avoid publishing any kind of opaque
| header-stuff. But also, most readers wouldn't know what
| to do with the information and -- less charitably--
| publishing evidence moves away from the framework where
| readers accept the reporters word on blind faith.
|
| Your position was entirely understandable: I declined to
| link to the repo or the two flagged HN threads about it,
| though I considered it, because I thought it would
| increase the risk that my comment would get flagged. I
| think your reply had the surprising consequence of making
| a really good example at how effective the suppression of
| info like this is at distorting the public discourse.
| stefan_ wrote:
| I think you are missing part of the irony here. A good number
| of those Hillary emails should have been on a government server
| in the first place, signed for entirety by the government for
| archival. Non-repudiation is an explicit design goal for the
| communication of public officials.
| newacct583 wrote:
| I think you're confused. Very few Clinton emails were ever
| leaked or released. The major leak people like to talk about
| was of John Podesta's emails. Podesta was a private employee
| of the Clinton campaign, he never worked at the state
| department. And of course being the campaign manager, having
| his email be provided by a government agency would have been
| a huge campaign finance violation to begin with.
| js2 wrote:
| I just realized after reading this that even though I host my
| personal domains with Fastmail, I'm delegated to their DKIM keys,
| so I can't rotate DKIM for my personal domain.
| Edmond wrote:
| I like the idea of non-repudiation, let the chips fall where they
| may when such authentic email is maliciously dumped.
|
| Perhaps a simple timestamped based appendage can be added for the
| sake of email client authentication. In other words reject the
| email if the signature is older than a few hours/minutes.
___________________________________________________________________
(page generated 2020-11-16 21:01 UTC)