No, you have confused messaging cryptography with "all of cryptography".
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.
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.
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.
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.
Which counterexample is that exactly? Your counterexample involving a store is incorrect -- the store's email would still be authenticated for a smaller amount of time which would allow your server to verify that it is a valid email that came from the store's servers.
EDIT: Since you responded with an edit, I suppose I should as well. Btw, you can reply to comments below, but you have to click on the comment's permalink/timestamp (the thing that says "1 hour ago") first.
I didn't see the comment you are referring to because it was a very high up ancestor. I only saw the comment I replied to which doesn't mention courts nor third-parties, which is why I asked you for an explanation. Please don't jump immediately to the conclusion that I did not read your comment.
Regarding the content, hamburglar's sibling comment is spot on. Non-repudiability shouldn't just be an afterthought. Accidental non-repudiability can have negative consequences itself. For one, relying on the kind of poor man's non-repudiability that DKIM gives you leaves powerful central entities with the ability to forge email while convincing almost everyone that it is legitimate.
From reading everything that you wrote, I think that your thesis is that email, specifically, ought to be non-repudiable. That might be a worthwhile idea, but it should be presented as such at the forefront. If others agree that this is a valid and useful concept, then a non-repudiability mechanism could be added to email explicitly, just as DKIM was added. But don't use DKIM for this, since it is a poor substitute.
I fully agree.
> From reading everything that you wrote, I think that your thesis is that email, specifically, ought to be non-repudiable. That might be a worthwhile idea, but it should be presented as such at the forefront. If others agree that this is a valid and useful concept, then a non-repudiability mechanism could be added to email explicitly, just as DKIM was added. But don't use DKIM for this, since it is a poor substitute.
If the choice was between "DKIM for non-repudiability" and "a better mechanism for non-repudiability", of course I would support the better mechanism. But that's not the choice here. The proposal here is to remove this accidental, partial non-repudiability mechanism that currently exists, and replace it with nothing. That would leave the world worse off, not better. DKIM protects innocent people from being framed for saying horrible things, and DKIM protects innocent people from guilty people who do horrible things. And sure, sometimes DKIM might be used against innocent people in some way, but the balance seems heavily in favor of DKIM (from the perspective of innocent people).
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.
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.
Let's not pretend that the world would move away from email if Google made this change. We both know that's not going to happen. Given that, can you explain why you think the world would be a better place when emails can be repudiated? When emails can be not be repudiated, innocent people can be framed for saying/doing things that they didn't do. DKIM protects innocent people from being framed. DKIM also protects innocent people against guilty people who commit frauds or other crime.
Please explain to me how I can make Amazon (or any other webshop) add non-repudiable contracts to their order flow? That's right, I can't. And no, I don't think that Amazon "owes" me non-repudiable emails, but now that we have non-repudiation by accident, it's certainly nice to have, and the world would be worse off if we removed that feature and replaced it with nothing.
Without non-repudiation, you don't automatically get to frame someone for whatever. You need to provide the usual (non-DKIM) evidence of whatever you're claiming.
And even with non-repudiation, you can still try and frame someone. Not having the DKIM signature might be suspicious in some circumstances, but it doesn't eliminate the possibility.
Second, "innocent" is not that simple.
I don't want my private communication to become public, or publicly verifiable. That doesn't mean I'm not "innocent". This is not a fringe concept: https://en.wikipedia.org/wiki/Nothing_to_hide_argument
"Give me six lines written by the most honest man in the world, and I will find enough in them to hang him." - Cardinal Richelieu
Yes, I agree we should have secure private messengers. But that has nothing to do with this discussion. First off, email is not a secure private messenger. Second, email would not become "more secure" by removing the accidental, partial non-repudiation that DKIM provides. Third, this comment chain that you are replying in right now, is about whether there exists any legitimate need for a third party to authenticate emails with DKIM after the emails have been sent. tptacek claimed that no such legitimate need exists. I've been arguing against this with a specific counter-example.
That's because we aren't discussing a proposal to switch from DKIM authentication to a different method of authentication. We're discussing a proposal to abandon the partial non-repudiation property that's accidentally provided by DKIM, and replacing it with nothing.
If you want concrete examples of how the partial non-repudiation property provided by DKIM is not "nothing", you have to look no further than the examples provided in OP.
Let me give you a scenario to consider. At my old company, there was a mail server that would DKIM-sign everything that was passed through it. Anybody who wanted to on the internal network could write an email with tampered headers (say, backdated, or "From:" someone else) and send it through this server. This was acceptable because the SOLE PURPOSE of this signing was improving SMTP deliverability. It tells other mail servers "yes, this SMTP payload actually originated from this company. Please do not treat it as spam." So given one of these signed messages, what can you argue about the contents? Nothing, other than "these did not come from a random spammer posing as this company."
You run risks when you assume a signature means something that the signer does not actually intend it to mean.
The example was that two parties are disputing a contract, the court is attempting to resolve the dispute, and the court has a need to authenticate the contract. Can you explain why you think that this is not a legitimate need to authenticate a document?
> I'm not sure (and decline to speculate) whether you're confused or malicious or some other problem entirely, but you are wrong.
You "decline to speculate", and then proceed to speculate anyway? Ok. Well, it's certainly easier to resort to calling me names, than actually defending your position with arguments.
Because it is not legitimate for a court to treat something that was not intentionally (ie, with something other than DKIM) signed as a signed contract. If one party did not sign that contract, a DKIM 'signature' doesn't change that. Conversely, if you have a argument that the document should be treated as a valid contract despite not having been signed, the lack of DKIM 'signature' is obviously irrelevant.
Not legitimate where? In Finland, where I live, there is no restriction on the form that a contract must take. A contract can be scribbled on a napkin, a contract can be oral, and yes, a contract can be written in email. You're claiming that a document should not be treated as a valid contract if it has not been signed, but Finnish law is pretty clear that a signature is not required for a contract to be valid. Furthermore, you claim that if a signature is not a requirement for a contract to be valid, then the lack of signature is "obviously" irrelevant. This is not obvious at all, and in fact is not true at all. As you surely know, sometimes the parties to a contract dispute what was agreed upon. Having a written contract is superior to an oral contract, because it is harder to dispute what was written, than it is to dispute what was said orally. In the same vein, it is harder to dispute a written contract with signatures, than a written contract lacking signatures. And in the same vein, it is harder to dispute an email that is DKIM validated, than an email that is lacking any sender validation.
No, I'm claiming that a document should not be treated as signed if it has not been signed. And drawing attention to (not "claiming") the fact that attaching^Whaving some third party such as Google attach a piece of networking metadata to it, does not constitute signing.
It sounds like you think that a "signed document" carries some sort of significance that an "unsigned document" does not carry, other than the value of the signature as evidence of a contract. I'm not aware of any such significance, at least not in the context of Finnish legislation. Perhaps if we are emailing a draft of a contract back and forth, the signature on a document can be used to specify which version is the agreed-upon contract as opposed to draft. But a similar proof could be attained without a signature, for example by recording audio of a verbal agreement which specifies the agreed-upon version of the contract. The signature does not carry any special significance.
In any case, no, I do not think that a DKIM signature is comparable to a handwritten signature. I would rather compare DKIM signature to fingerprints on a physical document. You might say "I've never seen this piece of paper in my life!" to dispute the validity of a paper contract, but your fingerprints on that paper would constitute significant evidence against your statement. DKIM signature of an email could be used in the same fashion.
No, he didn't, and to use quotes to claim someone said something that they didn't say is extremely disingenuous.
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.
No, it doesn't. The dispute isn't about the need for counterparties to authenticate each other. Yes, we all agree that it's good if email receivers can validate the authenticity of the sender. That's not at dispute. The question is, is it good if third parties also have the ability to authenticate the sender of an email at a later point in time (using DKIM specifically). tptacek claimed that there is no legitimate need for such a thing, and I provided a counter-example to that.