On Jun 22, 2013, at 9:49 PM, Michael Deutschmann
<michael(_at_)talamasca(_dot_)ocis(_dot_)net> wrote:
Ukh. This again.
I think I see what the problem is with the DKIM design community.
Most of you assume that once DKIM and an accessory protocol of choice
(DMARC, etc.) reaches a sufficient amount of respect from the RFC
machinery, it will magically be deployed absolutely everywhere it is
relevant.
Otis is just a shade more humble. He thinks the magical deployment will
occur, but will be accomplished by a jerk literal genie, who will try to
pass as much bad mail as possible while keeping to the letter of the
final DKIM spec.
Dear Michael,
A serious security vulnerability occurs when system administrators logically
follow DKIM deployment instructions. They likely have a reasonable desire to
avoid complains caused by reactive Bayesian filters. This filtering is
supplanted by more deterministic message acceptance based on trust established
by a DKIM signing domain specifically as suggested by the deployment
specifications.
Rather than DKIM admitting a process error where valid signatures are returned
for messages having invalidly prefixed header fields, the fix was to suggest
there is some undefined check left to some undefined subsequent agent. So much
for providing clean protocol layering. Use of DKIM requires an undefined
"degrading" process per section 8.15 to be implemented subsequent to signature
validation.
This is putting the cart before the horse since a DKIM validation process must
walk up and down the entire header field stack. It is also clear very few
domains implement the non-intuitive double listing of singleton header fields.
Even so called "high value" domains don't bother with this ugly hack. The
OpenDKIM implementation can place the cart behind the horse, but as a seldom
used option. An option that should be a REQUIREMENT.
RFC5863:
,---
5.4. Inbound Mail Filtering
DKIM is frequently employed in a mail filtering strategy to avoid
performing content analysis on email originating from trusted
sources. Messages that carry a valid DKIM signature from a trusted
source can be whitelisted, avoiding the need to perform computation
and hence energy-intensive content analysis to determine the
disposition of the message.
Mail sources can be determined to be trusted by means of previously
observed behavior and/or reference to external reputation or
accreditation services. The precise means by which this is
accomplished is outside the scope of DKIM.
'---
,---
8.4. Email Infrastructure Agents
...
Inbound: When an organization deploys DKIM, it needs to make
sure that its email infrastructure components that do not have
primary roles in DKIM handling do not modify message in ways
that prevent subsequent verification.
An inbound MTA or an MDA can incorporate an indication of the
verification results into the message, such as using an
Authentication-Results header field [RFC5451].
...
'---
,---
8.5. Mail User Agent
...
Inbound: An MUA can rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA/
MDA path (e.g., an Authentication-Results header field), or an
MUA can perform DKIM signature verification directly. A
verifying MUA needs to allow for the case where mail has been
modified in the inbound MTA path; if a signature fails, the
message is to be treated the same as a message that does not
have a signature.
...
'---
[RFC6376]:
,---
3.8. Input Requirements
...
Accordingly, DKIM's design is predicated on valid input. Therefore,
Signers and Verifiers SHOULD take reasonable steps to ensure that the
messages they are processing are valid according to [RFC5322],
[RFC2045], and any other relevant message format standards.
See Section 8.15 for additional discussion.
'---
Regards,
Douglas Otis
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html