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
