DKIM Validation

[J-J-Chiarella]

Enhancement request:

DKIM validation.

PGP ensures the identity of the human writing the message, but does not provide proof that the person is contacting you from the address or username from which he or she claims to be contacting you.

Also: DKIM is something I look for in my e-mails (I have DKIM Validator plug-in for Thunderbird). Much like even the most basic TLS cert by Let's Encrypt, the presence of a DKIM signature makes the originating web server a little more legitimate.

Deployment is not universal, but it is very good as a secondary and/or fallback signature on mail so that people can be sure of authorship and so that less than scrupulous politicians with horrible IT opsec cannot disavow everything.

With the robust and fast signatures of Ed25519 I have faith that DKIM will allow, in the near future, EdDSA in place of RSA and they may become more ubiquitous.

Filing this bug so that progress can be tracked.

Thank you all for your amazing work.

[yoshimo]

DKIM isn't really something that i would expose in the user facing mail client. Mailinglists and intermediate systems change the subject and insert footers, which in turn breaks the dkim signature. I think it does more harm than good.

[ArchangeGabriel]

@yoshimo They are mechanisms for those systems no to break DKIM. Valid DKIM signatures are a requirement in some case like when sending mail to GMail servers over IPv6, and this will become increasingly more required.

However, I do agree that DKIM is not somethings that should be checked at the MUA level, rather MTA/MDA. It does only authenticates the sending MTA, so this is pointless for the users, but interesting for the receiving MTA.

PGP ensures the identity of the human writing the message, but does not provide proof that the person is contacting you from the address or username from which he or she claims to be contacting you.

So what? If you trust the key, which means you trust the mail address linked to it, in which case would that matters?

[J-J-Chiarella]

Mailinglists and intermediate systems change the subject and insert footers, which in turn breaks the dkim signature.

The same is true of PGP signatures (both cleartext inline and attached PGP signatures in unencrypted format) and K-9 Mail supports them.

PGP ensures the identity of the human writing the message, but does not provide proof that the person is contacting you from the address or username from which he or she claims to be contacting you.

So what? If you trust the key, which means you trust the mail address linked to it, in which case would that matters?

There are situations where I may be replying to an e-mail and not know if the person is really a representative of bank@bankaddress.com or interview-invite@media-company.net.

Also, I may send an e-mail to someone from a mail account that the recipient trusts (representative@place-of-employment.org) and I may say that I wish to move the conversation to another account I own.

PGP signatures confirm who is writing the message, but they don't prove trusting the other party for honesty. I may be negotiating a contract with someone. I would want a verifiable record of the discussion. I may trust that the other party in the contract is the entity attached to a certain PGP key and that that certain PGP key is tied to that entity. But I may not trust that the other party is really an employee of --@cocacola.com. The other party may say (I'm signing this message to prove (1) that it is me and (2) I am sending this message from my --@cocacola.com account to prove that I represent Cocacola, Inc."

PGP verifies (1), but DKIM verifies (2).

DKIM isn't really something that i would expose in the user facing mail client.

Have it be an extra checkmark somewhere. The absence of the checkmark means no reason to panic, but to see it there is re-assuring. If the DKIM is absent, have K-9 Mail display the mail as it does right now with no changes. That's the protocol for PGP as well. If there is no PGP data, the client (on any platform) just doesn't mention PGP at all.

[ArchangeGabriel]

There are situations where I may be replying to an e-mail and not know if the person is really a representative of bank@bankaddress.com or interview-invite@media-company.net.

Also, I may send an e-mail to someone from a mail account that the recipient trusts (representative@place-of-employment.org) and I may say that I wish to move the conversation to another account I own.

PGP signatures confirm who is writing the message, but they don't prove trusting the other party for honesty. I may be negotiating a contract with someone. I would want a verifiable record of the discussion. I may trust that the other party in the contract is the entity attached to a certain PGP key and that that certain PGP key is tied to that entity. But I may not trust that the other party is really an employee of --@cocacola.com. The other party may say (I'm signing this message to prove (1) that it is me and (2) I am sending this message from my --@cocacola.com account to prove that I represent Cocacola, Inc."

PGP verifies (1), but DKIM verifies (2).

Isn’t all that covered by sending an encrypted email for this key to the address to verify?

[J-J-Chiarella]

Isn’t all that covered by sending an encrypted email for this key to the address to verify?

One response to this:

That is one method. However, it requires another step. It also requires both parties to support encryption. DKIM and unencrypted PGP signatures can be used with "dumb" e-mail and the contents verified later.

DKIM also does not require user intervention. It is automatically performed by the server. It also works as a fallback when the other party does not have PGP at all.

DKIM and PGP perform unique, complementary, redundant, and corroborating functions. In some ways, DKIM is just extra insurance. In some ways, unnecessary if you have PGP. DKIM is good for when PGP isn't feasible. DKIM also performs functions that PGP was never meant to do and could never do.

Isn’t all that covered by sending an encrypted email for this key to the address to verify?

Alternative response:

By this reasoning we don't need client-to-server SMTP over TLS or server-to-server SMTP over TLS because we can encrypt every message. We also wouldn't need secret passwords or individual e-mail accounts because we can sign e-mails or sign and encrypt e-mails. I am not trying to be facetious. This is what people do with PGP on Twitter: post or sticky post encrypted (or signed and encrypted) text.

But it is nice to have e-mail for a multitude of reasons, some of which are precision (instead of broadcasting) and some level of privacy. E-mail was improved with STARTTLS and then dedicated ports for TLS. DKIM was also an improvement upon e-mail.

[ArchangeGabriel]

Regarding the alternative answer: TLS still protects metadata from third-party listener though. But I see your point.

Anyway, my answer stays the same: in a not so long-term, DKIM should become mandatory and thus checked at MTA level. Whether having DKIM checked at MUA level meanwhile is good idea, I’ll leave that to the actual MUA dev. But I don’t think it is.

Also, note that DKIM without a DMARC policy is only partially useful, because if there is no DKIM signature, you don’t know whether that’s expected or not. So you just gain authentication of legitimate senders making use of DKIM, but don’t get ride of spoofer. Should the MUA also check DMARC? That doesn’t really make sense, since this is really a MTA targeted feature.

[J-J-Chiarella]

I agree that it should be a mail-transfer-agent matter and not mail-user-agent thing.

After all, we entrust our MTAs to establish TLS between servers. PGP is user-to-user, hence, an MUA feature.

Not quite. I cannot disable non-TLS mail for my posteo account because many servers in Asia, for example, have no TLS and I cant afford to not email those people or have their mail get rejected. I appreciate posteo offering the option for my account, nevertheless.

I would like to maximize security while maimtaining compatibility. For the same reason, clients still support STARTTLS for the few forsaken servers that refuse c2s tls (like MS Office 365 mail servers for large organizations).

Maybe it is better to entrust our servers or eventually force them to only do TLS or successful STARTTLS when talking to each other and to enforce DKIM and check validity.

In the meantime, I suppose we are forced to have MUA tells us both if mail was delivered over TLS and if it has a valid DKIM signature... or act as if S2S over successful STARTTLS on port 25 and DKIM effectively do not exist. This is basically the situation with DNS over TLS, a draft right now with no deployment on DNS servers or on web browsers or mail/messaging/XMPP clients.

---

Maybe K-9 Mail cpuld improve the Source Code view.

An advanced user can check source code of a message. At the top of the Source Code there could be a bold green text line:

SENT OVER TLS: YES/NO VALID DKIM: YES/ERROR/NA

[philipwhiuk]

I've had some Received header TLS checking code in my local repo for a while.

What I basically do is look for any none localhost connection and check it is reported in the Recipient headers as '(using TLSX with cipher ....)'. It's very marginal and it can miss cases because there's no standardisation on encoding this. For example, I've written custom regex's to match the style produced by MS and AWS.

Also any MTA in the path can modify Received headers others did or didn't add.

I've just enhanced it with a really basic form of DKIM check (just looking for the first Authentication-Results header that has either dkim=pass or dkim=fail).

All of this is hidden in the crypto information dialog which you can access if you have a crypto provider. None of it affects the symbol that gets shown there.

Some examples

https://drive.google.com/open?id=0BxQ_FfpsOsfIbEVXUm9aUzIxNVU https://drive.google.com/open?id=0BxQ_FfpsOsfIbkRXSzY0RXdiZWs

If you really wanted you could make it so you could tap on the icon and get the reason which typically contains the DKIM key size

There is of course lots of auth check types you could look whether MTA is doing. For example, SPF.

Really however, it's only interesting on an academic basis.

Yahoo.FR is perfectly happy to send me DKIM valid spam (which may or may not have been sent securely - the Received headers show NNFMP which may not be TLS secured).

In comparison the cryptography Mailing List ( http://www.metzdowd.com/mailman/listinfo/cryptography ) breaks DKIM when it re-distributes email because it adds the usual footer.

Amusingly while reading around DKIM I found a bad write-up on the benefits of DKIM by WikiLeaks. It's important to note that DKIM is added by the MTA, not the MUA, like PGP/MIME signatures and so it doesn't have the same guarantee.

[chadwickblane]

Isn’t all that covered by sending an encrypted email for this key to the address to verify?

Yes. @ArchangeGabriel

TLS still protects metadata

Except those relays that employ fallback.

[ArchangeGabriel]

Except those relays that employ fallback.

Which is an issue as is relay that don’t support TLS at all (or use a weak TLS configuration). The number of A+ SSL grade SMTP servers is ridiculously low, and the number of not even SSL/TLS supporting ones is abnormally high. Yes.