On 5/8/11 10:28 AM, Dave CROCKER wrote:
On 4/27/2011 2:21 AM, SM wrote:
I thought that the advancement of the specifications from Proposed to
Draft would not be too much of an effort as there are existing
implementations of RFC 4871. But then, this is the DKIM WG.
The effort is primarily created by folks choosing to respond about
issues that
have no constituency, are not real problems, and/or have already been
settled.
Folks can choose not to respond, when someone else raises a concern
that is not
an actual problem with the specification.
Responding makes it look as if the issue is real and significant. The
fact that
someone chooses to keep raising settled or non-issues does not
obligate others
to respond.
http://trac.tools.ietf.org/wg/dkim/trac/ticket/17
http://trac.tools.ietf.org/wg/dkim/trac/ticket/24
As in the case of ticket #24, A-Labels MUST not be assumed valid anymore
than message formats since RFC5890 restricts an additional 3,329 code
points not checked during DKIM signature validation. While some have
argued the message format must be handled by SMTP as the "proper" layer
for such validation, SMTP does NOT stipulate whether RFC822, or RFC5322
governs this format. In the case of DKIM, format compliance with
RFC5322 and RFC5890 is critical.
http://tools.ietf.org/html/rfc5321#section-3.3
.---
When the RFC 822 <http://tools.ietf.org/html/rfc822> format ([28
<http://tools.ietf.org/html/rfc5321#ref-28>], [4
<http://tools.ietf.org/html/rfc5321#ref-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 <http://tools.ietf.org/html/rfc822> or
MIME (RFC 2045 <http://tools.ietf.org/html/rfc2045> [21
<http://tools.ietf.org/html/rfc5321#ref-21>]) message
header section or message body. In particular, they MUST NOT reject
messages in which the numbers of Resent-header fields do not match or
Resent-to appears without Resent-from and/or Resent-date.
'---
RFC822 states:
,---
This specification permits multiple occurrences of most fields. Except
as noted, their interpretation is not specified here, and their use is
discouraged.
'---
Per the SMTP specification, highly deceptive messages are not excluded.
The current version of the revised DKIM specification introduction states:
,---
DKIM:
o is compatible with the existing email infrastructure and
transparent to the fullest extent possible;
o requires minimal new infrastructure;
o can be implemented independently of clients in order to reduce
deployment time;
o can be deployed incrementally;
o allows delegation of signing to third parties.
'---
By ignoring multiple headers not in compliance with RFC5322, indicating
such a message is properly signed is likely to provide highly misleading
message related information. When recipients expect message acceptance
relies upon valid DKIM signatures where signing domains match signed
From headers field as specified by ADSP RFC5617, many will become prone
to being misled by such ill considered DKIM results.
Rather than waiting for victims to accumulate, or to expect unspecified
"spam filtering" will apply criteria that DKIM should have imposed, DKIM
needs to adopt RFC5322 and RFC5890 requirements to avoid another 29
years of propagating the same type of mistake.
Murray Kucherawy at least responded by providing a basis for his
reasoning and suggested Section 8.14 and 8.15 addressed this issue.
These sections essentially state DKIM must _not_ enforce the newer
RFC5322 requirements, and instead permit the lax format specifications
offered by the underspecified RFC822 format. These sections even
suggest that this oversight _proves_ DKIM is unable to protect the
identity of the Author. Hardly a worthy goal that also completely
misses the goals expressed by the introduction and the DKIM Threat
Analysis RFC4686 Section 3.2. The allowance of bad input into the
signature validation process means that validation of a signing domain
will not offer a basis to trust messages when presented to the typical
subsequent mail user agent.
8.15
,---
DKIM allows additional header fields to be added to a signed message
without breaking the signature. This tolerance can be abused, for
example in a replay attack or a man-in-the-middle attack. The attack
is accomplished by creating additional instances of header fields to
an already signed message, without breaking the signature. These
then might be displayed to the end user or are used as filtering
input.
'---
8.14
,---
(This can also be taken as a demonstration that DKIM is not designed
to support author validation.)
'---
DKIM should not be limited to providing acceptance protections for the
"too big to block" domains. For example, any gmail message could be
used to spoof any other domain. DKIM is the perfect place to introduce
more stringent "signature validation" requirements since this would not
impact SMTP interoperability and could greatly enhance safer use of
email. The initial goal being sought by DKIM.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html