>> So right now, based on testing, if I receive an email that is DKIM
>> signed sent to a server running sendmail with envelope rcpt to: vs To:
>> header case discrepancies, I can expect DKIM to fail unless the signer
>> used relaxed canonicalized mode? What techniques and tools do I as a
>> recipient have to work around this issue for SpamAssasin which is
>> testing in a post sendmail delivery environment?
> The client has no options that are considered valid here. If you're presented a blob of signed data and a signature, and the verification fails, that's all you know; you aren't told why. Did something change? If so, what? Perhaps I don't have the right key? You really don't know.
In this case, I do know the key is correct because I've pinpointed and
had corroboration that Sendmail is the culprit changing the To: header.
I then reverse engineered the changes by having the pre-sendmail
processing file and figuring out what Sendmail was doing by behavior. I
could then edit the text and see that the signature was indeed valid.
So I know what changed, I know where it changed, and I know what program
did it. And it appears this could be a very large issue for DKIM-signed
emails that are received by sendmail where the case for the rcpt to:
envelope and the To: header differ. From my small server logs and weeks
of looking at this issue, the situation is not an obscure one.
I'd liked to be proved wrong. But I'm giving data and encouraging
people to recreate my research.
> The only thing you could do is engage in some heuristics (e.g., shenanigans) about how to reconstruct what the original blob of text was. In DKIM's case, you have a few things you can try, but in the grand scheme of things they're just guesses and we discourage them.
I wouldn't even try that in a live implementation... All my research to
date tells me that this is a systemic issue with sendmail that DKIM
signers need to be aware of. In my opinion, it sounds like if this
information is validated, DKIM should consider changing the default
signature to relaxed coupled with a major recommendation to use
relaxed. Sendmail is a very big player and this is a very real-world
issue not just an edge case.
> The first is to take the "z=" field, if there is one, and reconstruct the original header field set that got signed. This is actually a useful way to figure out what changed, but use of it to conduct a second verification has always been discouraged. It's meant strictly as a diagnostic tool.
> The second is to take a run at unraveling the damage by guessing at what may have changed. Knowing what you know now, you could try folding the To: domain to uppercase and repeating the test.
I did just that and used a milter to grab the pre and post sendmail
version received from Gmail. I then diffed the two and by trial and
error on a lot of test emails figured out the To: header was being
written identical to the envelope Rcpt To: data in sendmail breaking the
DKIM signature that gmail signed with.
The particular case I have pinned down is a user with an external MUA
using Gmail. I have not been able to reproduce the issue with Gmail's
web-based interface. I also spot checked my logs and had at least 200
cases in 12 hours on a small server showing the issue to be larger
rather than smaller.
> You could build up a library of common changes that break "simple" canonicalization signatures. (That might actually be valuable for future DKIM development efforts, but let me be the first to say "NOT IT!".)
>
> For "simple", even spacing matters. So this:
>
> To: foo<foo_at_bar.com>, baz<baz_at_blivit.org>
>
> ...changing to this:
>
> To: foo<foo_at_bar.com>, baz<baz_at_blivit.org>
>
> ...will invalidate a "simple" signature. And you'd have no idea why, because the space could've been removed anywhere, so you're guessing at where you need to try putting it back in, recomputing the hashes, re-testing the RSA verification, etc.
I agree completely. This is not a solution. Just a neat bit of
research to show the issue.
>
>> It seems to me, that we should be recommending that large ISPs, such as
>> Google, in light of this behavior with sendmail (including my tests
>> spanning from 8.13.1 to 8.14.5, the latest version) should use relaxed
>> canonicalized mode so that case-discrepancies on the To: header do not
>> cause signature validation errors.
> Gmail itself does use relaxed mode already, unless something recently changed, at least through the web interface. So I'm not sure why you're having this problem. Your submissions must be coming through some different path that uses "simple".
The signature in the example files I include are showing relaxed.
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=lYVEKO5MXo+cAf5wUNc37hh7jXayzO+c4Y+wRG+SgFM=;
b=crv4nFgQznK2NjBYYqd+Y0fuUN916hhWZmP4wtRVc2YdluezVLOFOQTSIR1aLGuIbF
KHDGEFJy4w2nnhJmKyiPaF3F0FNzbxTE2hzCqTWp/fusy+Pr8uHJeorIIawm1+cwIcFf
uMNmIWrxPS77QKNNAx3P+N6Qnyv+qcT0tWM+A=
So relaxed doesn't seem to fix the issue if the To: header's case is
changed somewhere between signing and verifying.
Regards,
KAM
--
*Kevin A. McGrail*
President
Peregrine Computer Consultants Corporation
3927 Old Lee Highway, Suite 102-C
Fairfax, VA 22030-2422
http://www.pccc.com/
703-359-9700 x50 / 800-823-8402 (Toll-Free)
703-359-8451 (fax)
KMcGrail_at_PCCC.com <mailto:kmcgrail_at_pccc.com>
Received on Fri Dec 16 2011 - 01:34:09 PST