DKIM: Rotate and publish your keys
diziet.dreamwidth.org
diziet.dreamwidth.org
Disclaimer: opinions are my own.
A DKIM signature does not prove that an individual sent the email, the key is not personal. A DKIM signature proves that the sending service is a delegated sender for the domain. Meaning that a correct DKIM signature proves that the part after the '@' symbol in the sender address is authentic. Not the part before that. If you want to use a personal signature, you can use S/MIME.
If you are a delegated sender for the domain, then you can use any sender name (the part before the '@' in the sender email address). This is how email works. The password that is typically required to authenticate with your outbound SMTP service if only enforced by that host.
So an email with sender address jane@example.com that is DKIM signed only proves that the email was send by a host that is a allowed to send email on behalf of example.com. It does not prove in any way that the email was sent by Jane.
Also, as others have mentioned, none of the email service providers will give you the private keys. I'd like to add that in most cases this won't even be possible, due to the use of HSMs.
So the proposed scheme would only work in a situation where you are owner of the DKIM key (thus in practice where you are the owner of the host sending the email), and where you also own the domain. It is trivial for a prosecutor to prove the owner of the domain, or the owner of the host that used the DKIM key. No amount of publishing keys will help you deny that ownership.
In my opinion it makes no sense in signing your email (whether it is S/MIME or DKIM) to prove that the email is authentic, and then complaining that there is no way to deny that the email is authentic once stuff goes bad.
The point of publishing the keys is that _anyone_ can then sign messages, making "ownership of the domain" a meaningless factor, no matter how much you can prove it.
The publication date of the DKIM record will be _after_ the email has been sent.
Obviously there is no real way to 'prove' the publication date of a DNS record, other than asking the DNS service provider for the logs maybe.
So IANAL, but I'd say the lack of provability of the publication date of the key makes it unsuitable for deniability. Just because the DKIM public key is currently public, does not prove in any way that it was already public when the email was sent.
Was that email even sent? Maybe it was forged after the key was leaked. This is what the author of the article is pointing out: The old private key being public, you can no longer rely on DKIM alone to prove anything about a document with a signature created with that key.
So to check if the property holds, the question is not: can you prove the key was public when the email was sent, it is a) can the adversary prove when the email was sent, and b) can the adversary prove that the key was not public at that timestamp?
On a), the adversary cannot just rely on Date: headers if those headers are signed by a public key, and the private key is now public - someone faking an email could just back-date the Date header to a date when the private key was not available, and hence an argument by the adversary that 'the Date header says it was sent at timestamp TS1, and at TS1, the key wasn't public, so therefore the email can't be repudiated' is not sound.
If the recipient of the email cooperates (or anyone who gets access to the email before the private key is published), they could, for example, hash all their emails, and then hash the list of hashes on a regular basis, and put that hash in a busy public blockchain. That would provide an upper bound on the email send timestamp, and, combined with a well-defined private key publication timeframe, provide non-repudiation.
It isn't actually possible to prove that the key was secure at some point in time prior to publication, publication of the key moots that discussion, which is probably going to generally be socially favorable enough of the time to be the better thing to do.
Most holders of keys do not own an HSM.
Hence my statement that this scheme only really works for self-hosted solutions, because you won't be able to obtain the keys from third-party email providers.
Edit: to expand on this a bit. The clustering will involve exchanging key material in encrypted form between each HSM. But that exchange is typically protected and authenticated by keys that are themselves attested as having been created securely in hardware. You can’t just inject your own keys to mitm that connection.
As I understand it, it should be impossible to export a private key from an HSM.
I'm not very familiar with HSMs though, so I might be wrong about this.
- Marking a key as “sensitive” means that the raw key material cannot be exported, except in encrypted (“wrapped”) form. Such an encrypted key can then be unwrapped to install it on another HSM. This key-wrapping facility is largely to allow backup or replication (but see below).
- Marking a key as “non-extractable” also means that it cannot be exported even in encrypted/wrapped form.
You generally configure a policy on the HSM to say that all private keys must be sensitive etc. It is pretty common (in my experience, dealing with banks primarily) to enable a policy that enforces all private keys to be sensitive and non-extractable. Proprietary mechanisms are then used to replication and backup of those keys (that effectively ignore those attributes/work at a lower level).
This is my understanding too. But if you have several HSMs which should all have the same key (needed for DKIM) then there needs to be some sync/export/import mechanism.
From what I understand, they can do more different things than "private key never leaves the device" asymmetric stuff.
a. The email is authentic.
b. Gmail has risked its reputation to "forge" the signature of an email it never sent.
That's strong evidence that the email is authentic! On the other hand, if Gmail were to publish their old DKIM keys, anyone with technical skills could have forged that signature.
As for why repudiation is desirable for emails, think protesters. They want to verify that the emails they receive are really from each other, but minimize their exposure in case the emails leak.
It's a common property for secure messaging systems, and I don't see why emails shouldn't have it too.
But yes, it is still pretty strong evidence.
Because emails, fundamentally, are not, and cannot be, a secure messaging systems.
You can certainly invent a better greenfield solution than email in 2023, but that’s not to say email doesn’t have room for improvement.
a. The email is authentic.
b. The service allows whoever administers the service to configure outgoing emails however they please.
c. There is a documented method by which the service allows you to override the sender address.
d. The service has risked its reputation to "forge" the signature.
The middle two options are extremely common in any business setting. Gmail supports both.
--
I am assuming, since your post does not appear to be agreeing with the parent comment, that when you say "authentic" you mean "sent or authorized by the individual named in the username field". If you mean "sent in a manner configured by some entity with authority on how the domain is used for sending email", then that is exactly the parent comment's point.
So I run my own email server for family (mostly) but a couple of friends. As the GP points out, the DKIM keys do not identify the user and in particular I can produce a validly signed email for any user of any of the domains my server hosts. Only CMS oblique S/MIME would provide non-repudiation in the cryptographic sense, and only meet e.g. eIDAS requirements if stored on a hardware token (i.e. in the EU, if I sign a PDF with the USB token I have, it is a "qualified signature" and it can be interpreted as legally binding).
On the other hand, there's a question as to what extent courts would understand the distinction between a valid and invalid/no DKIM signature. I guess what I'm saying is if it came down to a contractual dispute, "strong evidence" would not be good enough. If it came down to "this person organised a protest and that's a crime" I think even invalid DKIM would be fine. From what I've seen of court proceedings, mostly stuff shared here and so US stuff and not my native jurisdiction, but I have yet to see anyone cast doubt on an email's provenance based on DKIM. I'm going to go out on a limb and say in strongly democratic jurisdictions an email recovered from a server in someone else's inbox will likely be treated as valid unless there is something like an unusual sender IP to cast doubt on it. So "strong evidence of authenticity" probably won't come from DKIM.
In jurisdictions where protesting means you disappear, I doubt "check the DKIM keys!!!" is going to help - at least in part the police/courts might not be so worried about whether you are guilty or not.
Agree completely with the sibling comment that e-mail isn't suitable for secure messaging.
Even if you could theoretically create a mathematically plausible doubt it doesn't matter if a judge and or jury doesn't believe it.
Also both Google and the recipient can attest the message hit the server prior to the key being published. You MAY be in a position where your email provider is in a different jurisdiction and not inclined to cooperate but if bob the witness already gave up your message won't he give up the timeline breaking any hope of repudiation?
So all hope of an upside is basically a pipe dream. Lets talk about the downside you can now sign crap with Googles already published key and lie about the timeline. You can have "experts" go on TV and lie about authentication. Since most people know less than nothing on the topic it sounds on its face believable.
Criminal cases are not the only scenarios when authentication is relevant. Most email providers would not authenticate a message without a court order probably. And they may or may not retain sufficient information. A recipient whose messages were hacked would not want to authenticate the messages usually. A recipient who would benefit from disclosing a message the sender didn't want disclosed would benefit from forging a message usually.
Is it now not possible for people to go on TV and lie to people who know less than nothing about a topic?
So you're kinda right in the sense it's mostly authenticating the sending service's configuration and relationship to the domain, but kind of wrong on the front where the part before the @ isn't fundamentally authenticated. It is.
The User/User-Agent decoupling issue is still omnipresent, and adds a fundamental layer of uncertainty, that you are correct in. The fact we still seemingly need to grind that in to the uninitiated at times feels like there needs to be a cure to magical thinking formulated more than anything else.
You should probably stop "consulting on email security" if you don't understand that a DKIM-signed message proves the mailhost was authorized, and at least some of the headers could easily prove who sent the message.
I’d love to hear more about this. If I send an email from the Gmail UI, at a high level, how does DKIM ensure that Google can’t deliver the message with a different FROM header?
And, to clarify: your answer can’t involve trust/reputation because, well, both you and the person you quoted chose to use the word “prove”. Something being inadvisable and unlikely (Google forging emails) does not prove the opposite thereof.
In this context, DKIM definitely proves a user sent an email if you're willing to accept the assumption that the email provider is not arbitrarily sending emails that users did not write. This is perhaps not as strong a proof as if there were user specific (and user controlled) signing keys, although even then you're still making assumptions about the user's ability to control their keys, the software involved, etc. In the case of DKIM, it's certainly a much stronger proof that the user did indeed send an email than if you did not have the DKIM signature.
Absolutely. Propositions have a premise and a conclusion. In regular conversation, it is usually safe to omit part of the premise when it is assumed that everyone is on the same page, otherwise communication would be overly laborious. I agree 100%. An example in my response: I said nothing of the assumption that the cryptography in use hasn't been broken through quantum computing or other means as I think it's pretty obvious that, if verification of authorship hinges on the cryptography functioning as intended, it should be apparent that "the cryptography hasn't been broken" should be part of the premise. Communication would be practically impossible if we all have to add in an infinity other ground truths, like "the brains of humans of earth haven't been taken over by extraterrestrial parasites", or "we're not talking about a point in time before humans came into existence", or whatever.
> In this context, DKIM definitely proves a user sent an email if you're willing to accept the assumption that the email provider is not arbitrarily sending emails that users did not write.
I was waiting for this comment.
I'll restate your proposition, to make it more explicit:
"If an email provider won't arbitrarily send emails that users did not write, then a valid DKIM signature for a given email entails that the author as indicated in the FROM header was indeed the actual person/entity that wrote the email."
And that's fine!
So, if we take the premise to be true (as it seems you do), then we arrive at "a valid DKIM signature for a given email implies that the author as indicated in the FROM header was indeed the actual person/entity that wrote the email". Great!
However, to clarify why I wrote my original comment, here's the important bit from the OP:
> A DKIM signature does not prove that an individual sent the email, the key is not personal. A DKIM signature proves that the sending service is a delegated sender for the domain. Meaning that a correct DKIM signature proves that the part after the '@' symbol in the sender address is authentic. Not the part before that. If you want to use a personal signature, you can use S/MIME.
There's nothing about this that suggests that this commenter would find the earlier proposition invalid. More than that, if we are charitable (as we should be, if we want civil, productive discussion) and assume that they actually do consult in this space, there is no reason for us to assume that they don't already hold this proposition to be valid.
What the original commenter wrote could be restated as:
"If an email provider is not trusted to not send arbitrary emails, then DKIM is not sufficient proof to trust that the supposed sender actually authored the email -- it is only sufficient proof to trust that the email was delivered via the respective email service."
Looking at your response to the original commenter:
> You are technically correct (the best kind of correct), but in practice the nuance you're referring to does not make as much difference as you think. Yes, email senders could send email from whatever user they want or change the body from what the user wrote, but in practice of course they aren't doing that for the kind of email providers like Gmail that most people use.
Okay. Sure. You trust Gmail or whoever. That doesn't invalidate the second proposition -- that just means that (under your world view) it is not satisfiable.
Ultimately, what I was initially responding to:
> You should probably stop "consulting on email security" if you don't understand that a DKIM-signed message proves the mailhost was authorized, and at least some of the headers could easily prove who sent the message.
comes off as uncharitable at best, and undeservedly antagonistic and offensive at worst. Your response thus far hasn't provided a valid counterpoint.
And, to be clear, I actually disagree with the original commenters assertion:
> So the proposed scheme would only work in a situation where you are owner of the DKIM key (thus in practice where you are the owner of the host sending the email), and where you also own the domain. It is trivial for a prosecutor to prove the owner of the domain, or the owner of the host that used the DKIM key. No amount of publishing keys will help you deny that ownership.
(edit: TBC, I think this statement is true but doesn't effectively refute the utility of publishing the keys -- that, if everyone has the old key, the signatures of old emails become useless, while the signature of a new email can still be used to check authenticity... that authenticity, of course, being predicated on the assumption that Gmail or whoever isn't sending fraudulent emails, which admittedly is a pretty safe bet)
But that's orthogonal to what this sub-thread is discussing (whether second proposition above is valid), which started with someone snarkily implying that someone else is incompetent in their field.
That is what I wrote, I may have not have explained it correctly though, I was in a bit of a rush earlier today.
DKIM signs (a selection of) the headers, and the message body. The sender address (the 'from' header) is typically included in the signed subset of headers.
The domain (the part after the '@' symbol) authorizes the sender (the owner of the private key) to send email on behalf of the domain by publishing the public key (the DKIM DNS record).
So, if the signature is correct, then you know the message body, and the headers included in the signature (such as the 'from' header) are authentic (not tampered with since the host set added the signature). You also know that the sender is authorized to send email on behalf of the domain.
However, the sending host is free to place any arbitrary data in the headers, including the 'from' header, and sign it. There is absolute nothing that will prevent a malicious host from placing an arbitrary name before the '@' sign, except for integrity. So just because 'jane' was in the 'from' header, it doesn't mean that Jane actually wrote the message.
> and at least some of the headers could easily prove who sent the message.
No, none of them do. As I explained above, the sender is free to set the header values to any value. So just because there is a name in 'from' header, doesn't mean that that person actually wrote the email, or that it originated from one of that person's devices.
If you publish the DKIM DNS record for some third party email service, then that service could very well send email as you@yourdomain.tld. Should that somehow "easily prove" that you send that email? No amount of email headers are going to protect you from that kind of malicious behavior, that's just not how email works.
> You should probably stop "consulting on email security" if you don't understand [...]
Please refrain from insults like that. Reading your comment mocking my profession like that really ruined my evening.
If the deniability of a DKIM signed email reduces to "maybe Gmail spoofed emails from me", you don't have much of an argument. Yes, in a technical cryptographic sense, DKIM does not prove you sent the email, but when combined with how most providers like Gmail work, it makes it very likely you did send the email in every practical sense.
This isn't just a nitpicking nuance. In theory, rotating and publishing DKIM keys makes no difference to deniability since DKIM doesn't technically provide non-repudiation at the individual user level. In practice though, a service like Gmail implementing DKIM rotation and key publishing would make emails for a huge number of users more deniable going forward.
So pointing out DKIM only authenticates the domain only weakens the argument from "UserX at Gmail sent this email" to "UserX at Gmail sent this email provided no one found a suitable, currently unknown exploit at Gmail or performed an inside job".
For a journalist and most juries, provided the absence of any reasonable suspicion or evidence of weaknesses / foul play at Gmail, both statements have equal strength.
We all understand that really only the domain part is being authenticated, but if people believe in the good user identity and authentication practices of the sending domain then it's going to hard to rebut the presumption that the email is from the apparent sender.
If we posit that the purpose of DKIM signatures is preventing the injection of forgeries in the MTA chain, then authenticity is only an important property from the time that the message is sent until the time it reaches its addressed recipient. After that point, it's a bug, because long-term non-repudiation is not a purpose of DKIM.
Once a particular message is no longer traversing the network, there is no value (for DKIM purposes) in preserving the secrecy of the signing key.
I don't think this is the same article of which you're thinking. This is a tool to rotate DKIM keys and publish the old ones (in a sense, a scheme that replaces revocation).
It is also rather futile, since the prover can get the messages timestamped (myriads of ways, myriads of platforms), perhaps even steganographically in the correspondence, before the key is rotated.
the denialists can still rotate after shorter and even shorter intervals, but at some point the client software can't keep up and verify the email provider during usage, or rather resulting absence of usage...
it's pretty sad when technologists cave in under pressure from governments, politicians, lawyers and big firms keeping the lid on scandals... reducing the usage of cryptography to a purely symbolic cargo cult token or gesture...
Cryptography configured for exhibition only... but not in any court.
i.e. I demonstrated to others that I could have a DKIM signed email sent through gmail that was from a spoofed from: and it passed all DKIM tests (i.e. telnet gmail smtp server 25 (well with ssl, so openssl connect or something). smtp auth and do the standard MAIL FROM "SoSo <so@so> RCPT TO so@so data...... and it will look like a legit mail sent from SoSo.
DKIM's job isn't to protect against that.
I've just tested this, I generated a new app password in my Google Account and used that to send Gmail from Python.
Works fine when sending "from: <me@gmail>" with the app password, yet I can't change the sender since the SMTP auth then fails
"5.7.8 Username and Password not accepted. Learn more at https://support.google.com/mail/?p=BadCredentials"
Right, and there's a verification step in which you confirm you own (or at least control) the additional email address[es]:
https://support.google.com/mail/answer/22370?hl=en-GB
The OP appeared to be talking about somehow persuading Gmail into DKIM-signing an email from an address that wasn't theirs, though?
"I demonstrated to others that I could have a DKIM signed email sent through gmail that was from a spoofed from: and it passed all DKIM tests (i.e. telnet gmail smtp server 25 (well with ssl, so openssl connect or something). smtp auth and do the standard MAIL FROM "SoSo <so@so> RCPT TO so@so data...... and it will look like a legit mail sent from SoSo"
I've tried several times to do what I think is being claimed here and I'm struggling. For instance, telnet to a public mailserver I control, SMTP AUTH with an account with relay permissions, MAIL FROM so@so, RCPT TO my own Gmail, refused by GMail due to so@so's DMARC policy...
So, gmail does rewrite the From: header (well it keeps the name, but replaces the email within the <brackets> and adds a X-Google-Original-From header), and as this story is about senders (not receivers), spoofing would be protected in that regard.
However, what I remember now, is that I was proving that it doesn't tell you anything if the person in the To: was actually sent the mail.
i.e. even though DKIM protects the "To:" and "From:" headers it has nothing to do with the Rcpt To: (i.e. think how BCC works). So DKIM doesn't prove that an email was actually sent to someone (even if its on their machine now), just that someone might have faked a scheme where they sent an email with a To in the headers to someone, but the RCPT TO was not that person. So, it get signed as such, but isn't true. And in the case of gmail, the only reason there's any form of protection on the From: header is because gmail enforces a level of protection outside of dkim.
So what I must have done back then, was send people emails that looked like they were meant for Hunter Biden to receive that had all the DKIM validation check out, but were obviously never sent to him. (with all that said, for someone to have actually done this to Hunter Biden, they would have had to be playing such a long game, it's almost inconceivable to me, I was just proving that DKIM doesn't actually tell you if the supposed recepient is actually the receipient when sent via gmail, but as others have noted, if the From: header in the email isn't as locked down as gmail (and I'm sure not all are) / one knows of an exploit in gmail to subvert the From header in place editing, then it doesn't even help with that).
anyways, I apologize for exaggeration in my original post, its wasn't quite accurate. I hope I cleared up any confusion I caused.
We find the DKIM headers on the recipient's copy of messages, and they confirm information about the authenticity of the sender, right?
So a malicious actor in league with Alice prepares a laptop which purports to be Bob's (but isn't).... and on it there are DKIM-signed messages "From: Alice <alice@example.com>" and apparently "To: Bob <bob@example.com>", except they didn't actually go anywhere near Bob because they were "RCPT TO: <someone_else>"?
...or is there more to it?
I'd think that if one attacks the sender, one could even do it without the purported senders cooperation could also cause it to happen.
Now, especially because google rotates DKIM keys this would be such a long game attack that in my view, it's very improbable to be such a scenario.
Thinking about forging mail, in the case of senders who control their DKIM signing keys (me, for instance), if you have the sender's cooperation then you have access to their private DKIM key, can't you just sign any message you like?
No need for the messages you're forging and signing to go anywhere near any email clients or mailservers at all.
> As a user, you probably don’t want your emails to be non-repudiable. (Other people might want to be able to prove you sent some email, but your email system ought to serve your interests, not theirs.)
Other people being able to verify that an email really was sent by me does serve my interests, because such verification establishes trust. That's like claiming signing a contract isn't in your interest, because others will be able to prove that you agreed to its terms.
There are very few legitimate situations where you don't want non-repudiation (and in most of these, you shouldn't use a standard email system anyway), while in many cases, non-repudiation is legitimately valuable – for both sender and receiver.
As in the DKIM signature doesn't mean it was really the sender that sent it, but it does say that it wasn't changed after that.
DKIM, the technology considered by the article, does not prove this. The D stands for domain; it asserts nothing about the user that may have sent the email. Even if the domain is yours, you might delegate to another service or two, or you may have more than one user, or some automation in place. In any case, the recipient has little, if any, way to verify that and in all likelihood doesn't care that much; if they did, they wouldn't be relying on DKIM.
> There are very few legitimate situations where you don't want non-repudiation...
As a service provider, I'd probably want this. If it gets me out from the middle of someone else's dispute and doesn't have an ill effect on the service otherwise, I'd welcome it.
The combination of 1 and 2 work together. Yes, the mail provider could impersonate you, or could fail to do (1) correctly, but that is a different threat model to one where having no verification at all is okay.
In a lot of EU countries you can however digitally sign a container and mail that (under eIDAS those qualifying electronic signatures are legally binding, unlike random publicly trusted S/MIME signature).
But I guess if your alternative is fax, then a lot of thimngs are better than that.
The receiver has no control over that besides possibly ignoring those e-mails, therefore the e-mail services favor the interests of the sender over those of the receiver.
Are you saying that you do want people who are not your intended recipient(s) to be able to check copies of your emails to be able to verify that you actually wrote/sent those emails? Do you have an example of when this comes up in practice?
If you mean that you do want your recipient(s) to be able to verify your emails, the article is in agreement with you. The article states:
> When you send an email, that’s between you and the recipient. Normally you don’t intend for anyone, anywhere, who happens to get a copy, to be able to verify that it was really you that sent it.
where "anyone, anywhere, who happens to get a copy" is to say "an arbitrary person other than your intended recipient(s).
None of the above has anything to do with particular email message authenticity. Mechanisms for email authenticity, or additionally confidentiality, are S/MIME and PGP, where user controls the key, and it is up to them to make sure it doesn't leak.
I am providing email service to close to thousand users on dozens of domains over the course of fifteen years. The article does not make much sense to me from either postmaster's or mail user's point of view.
Only if you're on a shared email hoster. If you're the only one that has access to the mail server's signing keys, it's gonna be real hard to convince anyone that someone else signed that email.
Not convinced, the bigger problem today seems to be that someone claims that you sent something you didn't and if you do the above you can't disprove that.
You could sign your emails, but then the whole point of publishing the private keys is negated anyway...
The first signature for your future proof-of-authorship needs and the second for regular DKIM mechanisms to accept your email?
The first key isn’t ever published but you keep it if you need to prove your email was written by you.
The second key is rotated regularly with the private key published so that always have the ability to claim “I didn’t write that”.
You could have a mechanism to prove two emails are signed with the same key, without revealing the public key (e.g. using a zero-knowledge technique like zk-SNARKs) - but that might then be functionally equivalent to just revealing the key in terms of non-repudiation anyway.
Not really. The point is to deliver emails. Once it's delivered, it doesn't matter as much.
Someone comes to you and claims that a particular email was forged. They have no evidence of this forgery and no evidence that someone was even motivated and capable of doing such a forgery. You check and see that DMIM rotation is being done. Wouldn't the fact that there was a system set up specifically to allow someone to send an email and then lie about it make you very suspicious that they had done exactly that?
Forwarding an the email to a third party entirely defeats this scheme, doesn't it?
Not really, not when people have been arguing for this setup as a best practice for years for whole domains.
The advantage of deniability is that someone who manages to get one email of yours by any means can't prove to the world that you sent it, which can be an issue with things that are socially considered unfavorable as well as unsympathetic situations like corrupt politicians. There are disadvantages relating to harassment and corruption.
The article doesn't mention it but trusted timestamping during the validity of the DKIM key (plus as always having a copy of the public key) preserves the (limited) non-repudiation. Forwarding during the DKIM key validity could potentially work as a reliable timestamp depending on the details of the forwarding.
Given the options, I think I would rather have the class of problems that come with being able to prove where an email originated instead of the problems that arise from not being able to do so.
Proof protects a lot of innocents from bad actors in a lot of ways. Lack thereof protects whistleblowers and the like. It’s not a totally clear win one way or the other. I just suspect the prior helps more people.
I think the real solution to future breaches is ephemerality, which is why it’s critical for any secure messaging service to not only implement all-participant auto-delete, but to also make it easy to opt in to only for specific messages, since that brings the cost:benefit down to a point that it’s actually used.
The author doesn't understand what repudiate means, and therefore all the arguments are nonsensical.
To repudiate means, according to Cambridge dictionary "to refuse to accept something or someone as true, good, or reasonable"
So, when a transaction or email is repudiated, it means that someone is claiming that they didn't do it, despite the fact that it was done.
Non-repudiation is a characteristic of a system whereby a user of the system will find it difficult or "impossible" to repudiate that they did an action in that system.
So when the author claims in a title that "Non-repudiation of emails is undesirable" they are getting the words and meaning mixed up.
It is repudiation that is undesirable, and that's why non-repudiation is such an important characteristic of some types of system.
Deniability allows you to have low-stakes, casual interactions rather than having every stupid utterance timestamped and notarized for possible public viewing later.
For proving an old signature you'd lack an _authentic_ source for the signing public key that could only really be a dump of the historic DNS trace with all DNSSEC signatures (i.e. gmail does not use it).
Someone takes you to court and submits an old email that you sent as evidence. You can demonstrate that it is possible that anyone could have signed that email using the now-published DKIM key.
It is interesting that you can do this. A question is whether and when you would want to do so. Someone points out that good or bad conspirators might want to this: you send out anti-Putin emails and can deny it. Other ones?
Another point seems to be that DKIM is really designed not to verify emails, but to verify email senders.
<humor> Understanding this, I wonder if there are other things you can do with email using the same DKIM signing kind of mechanism. Like what about an OSIM signature, that uses a key only issued to email services that are not Google or Hotmail or one of the other big email people. If the message does not come from an OSIM host, then the email is delivered but goes into a o_spam folder? <end humor/>
People at real risk should probably be using something more secure like signal whereas people like US senators using a platform to communicate that can't be audited at need should probably go straight to prison on principal.
How many people have presented forged emails as real without a DKIM signature, and had the press say "nah, we're not going to report on that because DKIM is missing"?
A lot of wikileaks mails were verified with DKIM, and as I recall some of the people sending them initially denied it.
DKIM is routinely used to verify emails in cases where the evidence chain back to the source is unclear. I was personally involved in a forensic effort to verify DKIM signatures on the Hunter Biden laptop [3].
[1] https://github.com/associatedpress/verify-dkim [2] https://wikileaks.org/DKIM-Verification.html [3] https://www.washingtonpost.com/technology/2022/03/30/hunter-...
It could be very valuable to check the authenticity of old e-mails.
I am not a fan of blockchains but this is a rare case where they could be used to prove that the message is authentic by publishing the hash of the message (including the signature) in it. If the DKIM private key was published after the message was added to the blockchain then the message was clearly legitimate.
What makes you think that?
This is a discussion forum, you can't state thing and expect that no one will ask why.
Some people are literally so politics poisoned that they can't see that it cuts both ways. I can't wait until DKIM is used to prove something bad about Trump so everyone can flip their position on DKIM.
It isn't going to change anything, politics poisoned brains won't see the irony. But it's always funny to see anyway.
OK, I read the article, I operate my own email server and nothing I read convinces me I should do what they're suggesting.
Hello, you've been (semi-randomly) selected to take a CAPTCHA to validate your requests. Please complete it below and hit the button!
Had to set up DomainKeys to fix the issue.
It is critically important to keep the emails flowing independently from the DNS mafia/racket, like the web, but I guess we all very know that here on HN.
It's really not a racket and it's really not critical.
This means, we cannot agree.
The point of this proposal is that with rotation someone could not prove that a message hadn’t been forged retrospectively. It would then be almost impossible to establish an airtight chain of custody
The point is to forge emails, not domain keys.