Subject: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-15.txt

From: [email-masked]
Date: Mon, 11 Jul 2011 11:09:25 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF.

	Title           : DomainKeys Identified Mail (DKIM) Signatures
	Author(s)       : D. Crocker
                          Tony Hansen
                          M. Kucherawy
	Filename        : draft-ietf-dkim-rfc4871bis-15.txt
	Pages           : 77
	Date            : 2011-07-11

   DomainKeys Identified Mail (DKIM) permits a person, role, or
   organization that owns the signing domain to claim some
   responsibility for a message by associating the domain with the
   message.  This can be an author&#39;s organization, an operational relay
   or one of their agents.  DKIM separates the question of the identity
   of the signer of the message from the purported author of the
   message.  Assertion of responsibility is validated through a
   cryptographic signature and querying the signer&#39;s domain directly to
   retrieve the appropriate public key.  Message transit from author to
   recipient is through relays that typically make no substantive change
   to the message content and thus preserve the DKIM signature.

   This memo obsoletes RFC4871 and RFC5672.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-15.txt

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Barry Leiba <[email-masked]>
Date: Mon, 11 Jul 2011 16:15:34 -0400

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Domain Keys Identified
> Mail Working Group of the IETF.
>
...
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-15.txt

I believe that this version maintains rough consensus (not, I
recognize, unanimity) of the working group, and that it addresses the
DISCUSS issues raised by Pete.  This is the version we're sending back
to Sean and Pete, and is the version that will be approved if/when
Pete clears his DISCUSS ballot.

Thanks, everyone -- yes, everyone, including the dissenters on various
issues -- for working on this specification.

Barry, as chair

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 Jul 2011 17:29:01 -0700

8.15. Attacks Involving Extra Header Fields ...
,---
Agents that evaluate or apply DKIM output need to be aware that a DKIM
signer can sign messages that are malformed (e.g., violate [RFC5322],
such as by having multiple instances of a field that is only permitted
once), or that become malformed in transit, or that contain header or
body content that is not true or valid.  Use of DKIM on such messages
might constitute an attack against a receiver, especially where
additional credence is given to a signed message without adequate
evaluation of the signer.

These can represent serious attacks, but they have nothing to do with
DKIM; they are attacks on the recipient, or on the wrongly identified
author.
'---

This IS an attack on DKIM!  Acceptance, annotations, or sorting based
upon DKIM results that fail to exclude invalid pre-pended header fields
represent a threat NOT corrected by ANY reputation assessment for most
DKIM signing domains!  A malefactor that obtains a DKIM signed message
can ABUSE a signing domain by creating a phishing message through use of
pre-pended header fields whenever invalid pre-pended header fields are
inappropriately neglected by the DKIM verification process and are not
precluded by the little used and wasteful double tagging.

,---
Moreover, an agent would be incorrect to infer that all instances of a
header field are signed just because one is.
'---

This incorrectly describes the problem!  It is incorrect to infer the
bottom instance of a header field is the ONLY field that matters with
respect to protecting the integrity of a signing domain when
verification ignores invalid pre-pended header fields. Both signing and
verification can be attacked whenever invalid header fields are
neglected.

,---
A genuine signature from the domain under attack can be obtained by
legitimate means, but extra header fields can then be added, either by
interception or by replay.  In this scenario, DKIM can aid in detecting
addition of specific fields in transit.  This is done by having the
signer list the field name(s) in the "h=" tag an extra time (e.g.,
"h=from:from:..." for a message with one From field), so that addition
of an instance of that field downstream will render the signature unable
to be verified.  (See Section 3.5 for details.) This in essence is an
explicit indication that the signer repudiates responsibility for such a
malformed message.
'---

A high volume domain may sign harmless messages composed by one of their
users.  This domain may also ensure the From header field accurately
reflects the assigned address of the Author.  However, a DKIM message
can be replayed and then sent anywhere.  High volume domains are not
normally targets of phishing attacks and seldom employ the new and
dubious 'h=' double tagging of header fields.

The double tagging strategy remains dubious when any domain is
considered acceptable that does not impose the new double tagging strategy.
In that case, all domains remain at risk of being phished.  Even domains
that use ADSP and impose double tagging!

,---
DKIM signs and validates the data it is told to and works correctly. So
in this case, DKIM has done its job of delivering a validated domain
(the "d=" value) and, given the semantics of a DKIM signature,
essentially the signer has taken some responsibility for a problematic
message.  It is up to the identity assessor or some other subsequent
agent to act on such messages as needed, such as degrading the trust of
the message (or, indeed, of the signer), or by warning the recipient, or
even refusing delivery.
'----

Unless invalid pre-pended header fields are NOT ignored by the
verification process, DKIM will prove deceptive.  Especially when MUAs
are not DKIM aware.  When SMTP acceptance or annotations are based upon
reputation assessments of valid DKIM signature results, no protection
for recipients or signing domains can be offered when invalid
pre-pended header fields are ignored during verification.

,---
All components of the mail system that perform loose enforcement of
other mail standards will need to revisit that posture when
incorporating DKIM, especially when considering matters of potential
attacks such as those described.
'---

As indicated in DKIM's introduction, other email components are not
expected to change for safe incremental deployment of DKIM.  As such,
DKIM MUST stand on its own.

For a correction that addresses this issue see:
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

-Doug