Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

Thank you for offering your insights over the years here. I can very much understand how frustrating it can be and you articulated it spectacularly so I just wanted to tell you that you personally have posted many things over the years that I gained from. Thank you

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.

Start by reading the first sentence of my comment.

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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.

First, "innocent people can be framed" is not that simple.

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

> 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

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.

"with DKIM" is the part of your argument you've failed to back up. Yes, you have a counter-example that requires authenticated emails. You don't have one that requires authenticating emails with DKIM.

> "with DKIM" is the part of your argument you've failed to back up. Yes, you have a counter-example that requires authenticated emails. You don't have one that requires authenticating emails with DKIM.

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.

I'd argue that we currently have that "nothing" and are just trying to be explicit about it.

> I'd argue that we currently have that "nothing" and are just trying to be explicit about it.

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.

And yet all of those examples go poof very, very easily, based on something that's not in your control. So yeah, I think they're nothing.

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.

Nobody's talking about the world moving away from google. We're talking about the world simply not having non-repudiation built into email. A sender of an email doesn't owe you non-repudiation as a feature. Sorry if you think otherwise. Senders can add non-repudiation as a feature if they want to, which satisfies your purchase receipt scenario.

> Nobody's talking about the world moving away from google. We're talking about the world simply not having non-repudiation built into email. A sender of an email doesn't owe you non-repudiation as a feature. Sorry if you think otherwise. Senders can add non-repudiation as a feature if they want to, which satisfies your purchase receipt scenario.

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.

You can't force their DKIM signatures to be good forever either. You're basing some sense of security on a cryptographic property that simply isn't true. Would the world be worse off if you couldn't rely on DKIM signatures indefinitely? I don't know, are we worse off? Because whether you accept it or not, that's the exact situation we're in now.

So if something does not provide a perfect guarantee, it's "nothing"? You realize that handwritten signatures on a paper contract do not provide a perfect guarantee either? Signatures can be forged. And the paper is not going to remain in perfect condition forever, at some point in the future the paper is going to decay. Does that mean we can never know anything about anything? No. Of course we can have evidence about events which occurred in the world, even if the evidence doesn't provide a 100% guarantee of something, indefinitely. For example, a handwritten signature on a paper can be imperfect evidence that the contract took place, or a DKIM signature on an email can be imperfect evidence that the email is not a forgery.

Reply on news.ycombinator.com