Fwd: using dkim in thunderbird
Shane Caraveo
I've read up on dkim for other reasons, but then thought about it in
thunderbird. it seems it would be useful to have dkim verification in
thunderbird, which in part could help with spam/ham detection, but would
just be a nice user notification. I cant find any addons other than this:
https://addons.mozilla.org/en-US/thunderbird/addon/dkim-headers/
which relies on the receiving smtp server to have done the verification
(adding a Authentication-Results header which I imagine can be spoofed
with servers that do not verify dkim). My own smtp server (run by
dreamhost) provides dkim, but does not do dkim verification.
There's also another addon that does SPF:
http://razor.occams.info/code/spf/
Shane
_______________________________________________
tb-planning mailing list
tb-pl...@mozilla.org
https://mail.mozilla.org/listinfo/tb-planning
David Bienvenu
https://bugzilla.mozilla.org/show_bug.cgi?id=265226. That patch has
stalled a bit, I guess.
- David
Shane Caraveo
dkim verification. I'd like dkim verification to happen if it has not
been done (and maybe even if it has). I'm also not yet familiar enough
with dkim to know if the presence of the authentication-results header
is reliable or whether it can be faked, googling doesn't provide any
answer to that.
Shane
On 11-02-14 1:27 PM, David Bienvenu wrote:
> We have a patch that at least uses dkim to do spam detection -
> https://bugzilla.mozilla.org/show_bug.cgi?id=265226. That patch has
> stalled a bit, I guess.
>
> - David
>
> On Monday, February 14, 2011 1:15:53 PM, Shane Caraveo wrote:
>> Just an idea.
>>
>> I've read up on dkim for other reasons, but then thought about it in
>> thunderbird. it seems it would be useful to have dkim verification in
>> thunderbird, which in part could help with spam/ham detection, but would
>> just be a nice user notification. I cant find any addons other than this:
David Bienvenu
authentication-header is not reliable, and that verification is
problematic.
- David
Ludovic Hirlimann
> Just an idea.
>
> I've read up on dkim for other reasons, but then thought about it in
> thunderbird. it seems it would be useful to have dkim verification in
> thunderbird, which in part could help with spam/ham detection, but would
> just be a nice user notification. I cant find any addons other than
> this:
>
> https://addons.mozilla.org/en-US/thunderbird/addon/dkim-headers/
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=265226. That patch has
> stalled a bit, I guess.
>
> - David
days I had some conversations with Patrick Ben Koetter.
"We, my company "state of mind", looked into writing a Thunderbird
Add-On that does exactly what I layed out above, but we haven't done
much progress yet. Mainly due to projects we have been involved in and
deadlines we have to meet. May may be a time to start this..."
I think there are design flaws in dkim wrt to mailing list. But yes It's
a very good way to protect one's identity.
> which relies on the receiving smtp server to have done the verification
> (adding a Authentication-Results header which I imagine can be spoofed
> with servers that do not verify dkim). My own smtp server (run by
> dreamhost) provides dkim, but does not do dkim verification.
>
> There's also another addon that does SPF:
>
> http://razor.occams.info/code/spf
> https://mail.mozilla.org/listinfo/tb-planning
SPF is super-seeded by dkim and AFAIK all the big providers who offered
SPF have switched or are switching to dkim.
--
Ludovic Hirlimann MozillaMessaging QA lead
https://wiki.mozilla.org/Thunderbird:Testing
http://www.spreadthunderbird.com/aff/79/2
http://www.mozillamessaging.com/cacert.crt <- our root cert
Patrick Ben Koetter
Ludovic Hirlimann asked me to chime in. We met last year at the
opensourcedays.org annual convention where I gave a talk on DKIM and other
mail techniques <http://freedom.opensourcedays.org/2010/node/266>.
Ludovic asked me to share my point of view about DKIM in TB. I subscribed
the mailing list and copied this message from the archives. Be gentle if I
miss something that already has been discussed...
> We have a patch that at least uses dkim to do spam detection -
> https://bugzilla.mozilla.org/show_bug.cgi?id=265226 That patch has
> stalled a bit, I guess.
I don't think the patch is useful by what it aims for.
A broken DKIM signature is no indication that the message contains spam. It
only states the signature could not be verified.
The reasons e.g. server was unreachable, some mail processing instance broke
the signature, someone abused the server or even someone stole the private key
and the key hasn't been revoked yet are unknown.
I - personally - vote to treat DKIM verification results like this:
invalid signature
- raise notice
- tell reason e.g. cannot verify (TEMPFAIL), signature broken
key revoked
- raise alarm
- give advice
valid signature
- raise notice
- add bonus ONLY if sender has good reputation
> On Monday, February 14, 2011 1:15:53 PM, Shane Caraveo wrote:
> > Just an idea.
> >
> > I've read up on dkim for other reasons, but then thought about it in
> > thunderbird. it seems it would be useful to have dkim verification in
> > thunderbird, which in part could help with spam/ham detection, but would
> > just be a nice user notification. I cant find any addons other than this:
> >
> > https://addons.mozilla.org/en-US/thunderbird/addon/dkim-headers/
> >
> > which relies on the receiving smtp server to have done the verification
> > (adding a Authentication-Results header which I imagine can be spoofed
> > with servers that do not verify dkim). My own smtp server (run by
> > dreamhost) provides dkim, but does not do dkim verification.
Of course Authentication-Results can be spoofed. It remains the postmasters
job to 'clean' messages entering his domain from headers that must not be
trusted. The popular content filter amavis, for example, cleans messages from
headers that must not be trusted. The trust list is expandable...
Besides Authentication-Results headers carry the verifying hosts hostname,
which can be used to decide if the header should be trusted:
Authentication-Results: mail.state-of-mind.de; dkim=none (no signature)
header.i=unknown; dkim-adsp=none
I'm using dkim-milter and IIRC dkim-milter removes Authentication-Results:
headers that carry its own hostname before it adds its own. Other software
will probably behave accordingly. So forgery should be limitable and workload
could be done by the server making TB feel snappier.
But using Authentication-Results headers won't help in all use cases described
above. They are fine to indicate an (in)valid signature, but useless if you
open a message that used to be valid, but isn't anymore because the signing
key was revoked a minute after verification had taken place...
Implementing all use cases would mean not only to add logic to TB that checks
for Authentication-Results: headers, but also functionality that does DNS
lookups and checks if the key is still there or if only the TXT record is
there but empty, which is the official way to indicate the key has been
revoked.
Regards,
p@rick
--
state of mind
Digitale Kommunikation
Franziskanerstraße 15 Telefon +49 89 3090 4664
81669 München Telefax +49 89 3090 4666
Amtsgericht München Partnerschaftsregister PR 563
Alex Reinhart
Glad to see there's interest in it, though; I'll do some work on it next time I have spare time.
Regarding the initial comments on doing DKIM verification through Thunderbird: I believe the spec recommends against this, because there's various circumstances the verifier has to be aware of. A verifier in a complicated mail network may be set to trust certain servers, ignore certain problematic headers, rewrite headers in mailing list messages, and so on; replicating this in Thunderbird would be difficult. Fortunately the big email providers (Gmail, Yahoo, etc.) all do Authentication-Results headers.
- Alex Reinhart
Alex Reinhart
Also, regarding key revocation -- does DKIM provide a method for key revocation? It was my understanding that one simply withdraws the public key from DNS, which would make validation fail in a way indistinguishable from any other temporary DNS failure.
- Alex Reinhart
Shane Caraveo
> The patch accounts for these conditions; the Authentication-Results
> header gives results that discriminate between an invalid signature
> and a signature error. In cases where the signature could not be
> verified, the patch ignores it -- an unknown signature is no
> different from no signature.
The problem with authentication-results is that is can be spoofed unless
the receiving smtp server cleans headers or does verification itself
(thus replacing a spoofed headers). Essentially, there is no way for
Thunderbird to trust authentication-results except by white-listing a
set of isp's that are known to clean headers and do verification.
> Also, regarding key revocation -- does DKIM provide a method for key
> revocation? It was my understanding that one simply withdraws the
> public key from DNS, which would make validation fail in a way
> indistinguishable from any other temporary DNS failure.
Verification should be done once with the message being stamped. From
my reading of DKIM, it does not define anything around revoking keys,
simply that they can be revoked. authentication-results appears to be
that stamp, however, the client software can never trust it. Either any
use of it is on the server only, or the user must have knowledge that it
can otherwise be trusted. I think any reliance on
authentication-results in client software is flawed and open to abuse.
Shane
Shane Caraveo
verified. That breaks the trust of that mechanism. Since dkim is not
supported/verified by all smtp servers, there is simply no way to know
for sure without doing the verification.
In your description, the effort of filtering "this is fail" using
auth-results is fine. For the effort of saying "this is valid"
auth-results fails.
If the UI had a column with a happy face or sad face for each email
based on dkim, using auth-results we would only be able to reliably show
a sad face. I want to see happy faces.
Shane
On 11-02-15 11:32 AM, Alex Reinhart wrote:
> My reasoning went like this:
>
> - If my MTA does not verify DKIM and does not strip
> Authentication-Results, the header can be forged. However, the patch
> only takes action when the Authentication-Results header reports an
> invalid signature, so a forgery can only trip the phishing warning.
> Forging a pass will gain nothing. - If the MTA does verify DKIM but
> does not strip prior Authentication-Results headers, we'll only pay
> attention to the first. - If the MTA verifies DKIM and strips prior
> headers, we're safe.
>
> Is there a condition in which a forged Authentication-Results header
> can cause harm, based on this reasoning?
>
> - Alex Reinhart
Shane Caraveo
On 11-02-15 11:55 AM, Alex Reinhart wrote:
> The DKIM standard (RFC 5451) specifically advises against showing
> happy faces, under any conditions, even with a trusted verifier,
> unless we have further information about the originating domain:
Ok, let me try to provide a more real world example of why I feel dkim
verification and some indication about the results would be useful.
My email provider does not verify dkim even though it provides dkim in
sent messages. Seems odd to me, but nothing I can do about it.
dkim can provide sender domain name verification and some level of
tamper resistance. If I receive an email from my bank and it has dkim,
I can know the sender domain is verified, and at least the portions
covered by the signature have not been tampered with.
In this situation, I don't need a reputation service to tell me that
mbna is ok, I need to know the email came from mbna and is unmodified.
I don't really care about emails from example.com, I dont trust them
anyway. dkim verification could provide one more level of assurance
about emails from organizations I already 'trust'.
Alex Reinhart
- If my MTA does not verify DKIM and does not strip Authentication-Results, the header can be forged. However, the patch only takes action when the Authentication-Results header reports an invalid signature, so a forgery can only trip the phishing warning. Forging a pass will gain nothing.
- If the MTA does verify DKIM but does not strip prior Authentication-Results headers, we'll only pay attention to the first.
- If the MTA verifies DKIM and strips prior headers, we're safe.
Is there a condition in which a forged Authentication-Results header can cause harm, based on this reasoning?
- Alex Reinhart
Alex Reinhart
An MUA SHOULD NOT reveal these results to end users unless the
results are accompanied by, at a minimum, some associated reputation
data about the authenticated origin identifiers within the message.
For example, an attacker could register examp1e.com (note the digit
"one") and send signed mail to intended victims; a verifier would
detect that the signature was valid and report a "pass" even though
it's clear the DNS domain name was intended to mislead.
It also states, in section 7.2:
Until some form of service for querying the reputation of a sending
agent is widely deployed, the existence of this header field
indicating a "pass" does not render the message trustworthy.
I don't think it's feasible to show happy faces unless we have other reputation mechanisms. For now, my patch just tries to show sad faces when appropriate.
- Alex Reinhart
Patrick Ben Koetter
> The patch accounts for these conditions; the Authentication-Results header
> gives results that discriminate between an invalid signature and a signature
> error. In cases where the signature could not be verified, the patch ignores
> it -- an unknown signature is no different from no signature.
Hmmm, is it wise to make no difference between an unverified signature and and
no signature?
If a message has no signature, it can't be verified. That's permanent.
OTOH if a message does have a signature, but it can't be verified it may be
the result of a temporary error e.g. because the DNS server responsible is
down or responding too sloooooowly.
There's no useful way to have the server re-examine the signature, but TB
would be in a position to do that. If the temporary error is gone then, the
signature might prove valid providing just the extra reputation the sender had
in mind when she sent the message.
Complex and maybe because of its complexity the reason not to discriminate
because it might ask too much from non-expert users.
> Also, regarding key revocation -- does DKIM provide a method for key
> revocation? It was my understanding that one simply withdraws the public key
Yes, it does. The trick is to leave the DNS entry there, but leave it empty.
What it doesn't specify though is a way to tell why the key was revoked:
p= Public-key data (base64; REQUIRED). An empty value means that
this public key has been revoked. The syntax and semantics of
this tag value before being encoded in base64 are defined by the
"k=" tag.
INFORMATIVE RATIONALE: If a private key has been compromised
or otherwise disabled (e.g., an outsourcing contract has been
terminated), a signer might want to explicitly state that it
knows about the selector, but all messages using that
selector should fail verification. Verifiers should ignore
any DKIM-Signature header fields with a selector referencing
a revoked key.
See also: RFC 4871 <http://www.rfc-editor.org/in-notes/rfc4871.txt>
p@rick
Alex Reinhart
Hmmm, is it wise to make no difference between an unverified signature and and
no signature?
[DKIM] advises that if a message fails verification, it should be treated as an unsigned message.