5 ms·

For context, this idea of publishing the secrets has come up again recently after DKIM was used to prove the authenticity of the “smoking gun” Hunter Biden emai

by zaroth 6y ago

For context, this idea of publishing the secrets has come up again recently after DKIM was used to prove the authenticity of the “smoking gun” Hunter Biden email. [1] More generally, non-repudiation is a great feature if that’s what you’re going for. Often times it’s not actually what you needed at the time, but gets thrown in anyway because it’s harder to design a signing protocol without that property than with it. So in the sense that non-repudiation isn’t a core requirement of DKIM you’d like to have the crypto algorithm which meets just the DKIM requirement and no more — yes, this email definitely came from an authorized server and hasn’t been tampered with, but without inherently proving that the email is not a forgery years later. On the other hand, DKIM having this property is actually extremely useful and nice to have a lot of the time, not the least of which in the Hunter Biden case, or for the purpose of authenticating any particular historical email. [1] - https://github.com/robertdavidgraham/hunter-dkim https://github.com/robertdavidgraham/hunter-dkim

tptacek 6y ago
Purely from an engineering perspective, in a setting where we care about privacy --- ostensibly, email is one of the settings where we care most about privacy --- the ability of a stranger to authenticate any particular historical email is a fairly grave vulnerability. Privacy-preserving systems go out of their way not to have it. You may have some kind of public policy or archaeological argument in favor of the vulnerability, but then it's hard to see how the same argument doesn't suggest we should compromise the entire confidentiality of every email; after all, that would make research a lot easier.
compsciphd 6y ago
just for the record, while I mostly agree with the analysis on that page, I believe the author tries to make a stronger case than it really is. 1) DKIM verifies the To: header, not the "rcpt to" receipient. The To: header has no value in determining who actually received the email. (Ex: you receive the email via BCC, you can't verify that the recipients listed in the To: actually got the email). 2) GMail actually does let users "spoof" the From: line. it needs cooperation from the "owner" of the address you want to use in the From line, but it is possible, and once set once, is never reconfirmed. so, as I said, while I generally agree with the analysis, but I think 2 statements it makes are a bit too strong 1) "it was sent from this specific account, v.pozharskyi.ukraine@gmail.com" - It could have been sent via a different account that got the specific account's permission (either via a hack of sorts or cooperation) to spoof it. I'd agree that this isn't that likely. 2) "the intended recipient was to the account hbiden@rosemontseneca.com" - all we can know is that this was the To: line, it is very easy to spoof this. (every email one gets via BCC is essentially spoofing this). do I think either points are very likely? Not so much, but any page trying to prove the authenticity needs to address the limits of the analysis, which the author didn't do. Of course there are other assumptions we make, notably that no one was able to steal or crack Google's old DKIM key. I wonder how many google employees would have had access to this DKIM key over time (and if security procedures might have been relaxed once it was "expired" and the public portion no longer distributed).
- fogihujy 6y ago
  DMARC does a decent job of solving a few of those points. Alas, that only proves the point that another commenter made about server-to-server SMTP being a hack-job piled on top of another hack job. The one thing DKIM is good at is for protecting the From-header and body from modification, allowing receiving servers to verify that the sender is genuine whenever they receive an incoming message (when combined with DMARC that is). For anything else, use PGP, S/MIME, or something else that actually does end-to-end encryption/signing.

by zaroth 6y ago

tptacek 6y ago

Purely from an engineering perspective, in a setting where we care about privacy --- ostensibly, email is one of the settings where we care most about privacy --- the ability of a stranger to authenticate any particular historical email is a fairly grave vulnerability. Privacy-preserving systems go out of their way not to have it. You may have some kind of public policy or archaeological argument in favor of the vulnerability, but then it's hard to see how the same argument doesn't suggest we should compromise the entire confidentiality of every email; after all, that would make research a lot easier.

compsciphd 6y ago

just for the record, while I mostly agree with the analysis on that page, I believe the author tries to make a stronger case than it really is. 1) DKIM verifies the To: header, not the "rcpt to" receipient. The To: header has no value in determining who actually received the email. (Ex: you receive the email via BCC, you can't verify that the recipients listed in the To: actually got the email). 2) GMail actually does let users "spoof" the From: line. it needs cooperation from the "owner" of the address you want to use in the From line, but it is possible, and once set once, is never reconfirmed. so, as I said, while I generally agree with the analysis, but I think 2 statements it makes are a bit too strong 1) "it was sent from this specific account, v.pozharskyi.ukraine@gmail.com" - It could have been sent via a different account that got the specific account's permission (either via a hack of sorts or cooperation) to spoof it. I'd agree that this isn't that likely. 2) "the intended recipient was to the account hbiden@rosemontseneca.com" - all we can know is that this was the To: line, it is very easy to spoof this. (every email one gets via BCC is essentially spoofing this). do I think either points are very likely? Not so much, but any page trying to prove the authenticity needs to address the limits of the analysis, which the author didn't do. Of course there are other assumptions we make, notably that no one was able to steal or crack Google's old DKIM key. I wonder how many google employees would have had access to this DKIM key over time (and if security procedures might have been relaxed once it was "expired" and the public portion no longer distributed).

fogihujy 6y ago
DMARC does a decent job of solving a few of those points. Alas, that only proves the point that another commenter made about server-to-server SMTP being a hack-job piled on top of another hack job. The one thing DKIM is good at is for protecting the From-header and body from modification, allowing receiving servers to verify that the sender is genuine whenever they receive an incoming message (when combined with DMARC that is). For anything else, use PGP, S/MIME, or something else that actually does end-to-end encryption/signing.