On 6/22/11 11:14 AM, Dave CROCKER wrote:
Folks,
The bottom line about Doug's note is that the working group extensively
considered the basic issue of multiple From: header fields and Doug is
raising nothing new about the topic.
A quick summary of the technical point at the core of Doug's concern is
that the presence of multiple rfc5322.From header fields does appear to
represent a plausible attack vector, but it also violates RFC5322 -- and
RFC822, if anyone is worried about the history of this issue. DKIM
(RFC4871) requires that the signing engine be handed a valid RFC5322
message. Hence the burden of ensuring that there is only one From: field
rests outside DKIM.
First, thank you for your response.
I must ask however where do you see this burden being placed? If not on
DKIM where?
To clarify, the message format standard authored by you back in 1982
imposed no limit on the number of header fields and this was not revised
until 2001.
RFC822 Section 4.1 Syntax states:
,---
This specification permits multiple occurrences of most
fields. Except as noted, their interpretation is not
specified here, and their use is discouraged.
'---
The current RFC4871bis only vaguely *recommends* compliance.
3.8. Input Requirements
,---
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.
'---
Another decade has passed and SMTP still fails to impose strict message
format enforcement after limits were imposed on Orig-date, From, Sender,
Reply-to, To, Cc, Message-id, In-reply-to, References, and Subject.
Voicing opinions of protocol layering lends permission to DKIM
implementers to also ignore these limits. :^(
RFC5321 Section 3.3 states:
,--
When the RFC 822 format ([28], [4]) is being used, the mail data
include the header fields such as those named Date, Subject, To, Cc,
and From. Server SMTP systems SHOULD NOT reject messages based on
perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message
header section or message body.
'--
It is not reasonable to expect SMTP will impose necessary restrictions
able to prevent deceptive DKIM results anytime in the near future. As
the DKIM draft states, SMTP is not enforcing header limitations now.
You expressed concern over protocol layers. What do you call the
protocol layer you expect to be making these needed checks? Is this
some highly opaque spam filter protocol layer? Will this layer guess
whether DKIM checked RFC5322's header field requirements? If not
guessing, how is this check being signaled?
Those wishing to implement secure systems need to know whether a high
value From header field might be mistakenly accepted based on signatures
offered by some large free email provider. Free email providers often
don't care whether header fields might be pre-pended when their
reputation is based upon their volume. They are also unlikely to
implement a wasteful fix of double listings of signed headers which then
exposes high value domains to abuse well beyond their control.
The DKIM specification claims it can be incrementally deployed. One
might presume that acceptance might be based upon the signing domain.
If not DKIM, what protocol layer ensures header field limitations have
been imposed to prevent the signing domain's DKIM's assurances from
becoming deceptive or evil?
For reference, Doug posted a related blog recently and I posted a
response yesterday:
<http://www.circleid.com/posts/searching_under_lampposts_with_dkim/>
Others are posting responses also. The Comment mechanism, to the
Circleid article, is being used to list these additional responses.
Inline comments...
On 6/21/2011 6:50 PM, Douglas Otis wrote:But,
RFC4686 Introduction states:
...
While several threats to DKIM were considered, multiple From header
fields were
neglected. This document only focused on use of multiple addresses
within the
From header field.
Any possible omissions in an Informational threats document -- done 6
years ago and before the signing specification (RFC4871) was written --
is of marginal relevance, at best.
Nevertheless, RFC4686 missed the threat created by multiple From header
fields.
It should be noted that Signing Practices are referenced off a domain
found in
the From header field which also assumes only one will be present.
It also should be noted that Signing Practices (ADSP) issues are
irrelevant to the candidate RFC4871bis effort, which pertains only to
the signing specification.
ADSP depends upon RFC4871's output where it is not possible to achieve
the desired policies when pre-pended From header fields are ignored.
This indicates the DKIM specification is seriously flawed.
It indicates that there is an issue, not that it is DKIM's
responsibility to solve it.
What protocol do you expect will solve this issue?
While DKIM may not offer author validation,
Does not. Not may not. It's a simple and direct fact.
I never said DKIM authenticated the From header. DKIM is expected to
authenticate a binding of the signing domain with the From header at a
minimum. It might also include other headers and the message body.
it was intended to establish an accountable domain for
the signed message content that at a minimum includes the From header
field.
And it does that. But it does not make any assertions about the
/validity/ of any of the data it signs, nevermind any of the data it
does NOT sign.
The intent of DKIM is completely missed when a pre-pended From header is
ignored in signature validation. It is also not reasonable to expect
all subsequent mail handling will retroactively adopt DKIM's bottom-up
header selection methods.
There are NO valid reasons for a valid signature to include multiple
From header
fields! Allowing multiple From header fields is _EVIL_ and destroys
DKIM's
intended purpose as defined by prior work.
It actually has no discernible effect on DKIM's utility, nor have there
been reports from the field of problems in 6 years of deployed use.
Is it reasonable to wait for massive exploitation? Social engineering
attacks need not occur at high frequencies before significant damage can
be created. It seems users are seeking social network communications in
part because they don't wish to sort through high levels of fraud.
Free email providers likely use DKIM to gain increased acceptance by
taking
advantage of their "too big to block" volumes. For these domains, their
reputation is understood to offer little assurance of their overall
integrity
while perhaps limiting what is allowed in the domain portion of the
From header
field.
This appears to be a political rant.
No. This was to counter several who expect reputation systems can deal
with this type of abuse. They can't when DKIM reports valid signatures
when messages contain multiple From header fields.
By allowing a pre-pended From header field to not affect the validity
of a DKIM
signature according to the specification means the UNDERSTOOD source of a
message can NEVER be trusted through the aid of DKIM.
That statement well might be correct, but that's OK, since DKIM does not
make assertions about "source" validity, except in terms of the separate
DKIM signing identifier (in the DKIM-Signature: header field.) The
signer is sometimes referred to as a source. However DKIM makes no
assertions concerning the Author or Originator [RFC5598].
DKIM does assert, at a minimum, a signing domain is bound to the From
header field. This is important whenever DKIM is used as a basis for
acceptance. However, this binding is rendered meaningless when a
pre-pended From header field is ignored, and yet is predominately
displayed to the recipient.
The general goal of DKIM cryptographically binding at a minimum the
From header
field of the message content to a domain was to act as a trust basis for
acceptance.
The general goal is to attach an identifier than is reliable and valid,
and it does that. The identifier can be used for developing a reputation
assessment of message streams signed with that identifier.
What affect will this have on a massive Free email provider being
exploited with some pre-pended From header fields? The answer is NONE.
Reputation will not solve the issue of abuse of "too big to block"
providers.
DKIM also purports to allow incremental deployment without requiring
additional undefined filtering be introduced in mail transfer or mail
user
agents. Clearly, the incremental deployment statement conflicts with the
original goals due to the neglected input validation flaw.
I have no idea what the above means.
The hand waving about something other than DKIM fixing its bogus results
will not allow for incremental deployment.
Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
And it nicely shows that the working group considered the issue.
This version of DKIM also introduced use of RFC5890 instead of
RFC3490, which
allows use of the German esset and the Greek final sigma, drops
string-prep, and
defines 3,329 invalid code points. Unfortunately, this version of the
DKIM also
failed to exclude use of Fake A-Labels, which when presented to the
user may
also prove highly deceptive.
Excellent. Now it is also DKIM's job to fix problems with Unicode...
No. DKIM can not safely offer a basis of trust without also ensuing the
domain conveyed to a recipient is not visually deceptive. This requires
ensuring against Fake-A labels as defined by the referenced RFC5890.
Soon there will be many unfamiliar TLDs where users may have difficulty
discerning which domains are published within a private zone or are
registered. Either way, recipients are better served by ensuring Fake
A-labels are never used to validate DKIM signatures.
It is also important to ensure against use of U-labels as well. This
should not become a problem since the range of the character code-points
should exclude this problem.
Details of this concern were stated in the tracker at:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
wrong citation.
Thanks. That should have been:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17
-Doug
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
