Subject: Re: [ietf-dkim] Ticket #17

From: SM <[email-masked]>
Date: Wed, 27 Apr 2011 02:21:58 -0700

Hi Doug,
At 18:43 26-04-2011, Douglas Otis wrote:
>Not validating input creates a bigger mess when used in conjunction with
>RFC5336bis.  As such, it seems unfair for the DKIM WG operating within
>the Security area to close and then hand a mess over to the Applications
>area EAI WG.

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.

I don't see any issue between the Security Area and the Applications 
Area.  I don't recall DKIM being discussed in the EAI WG.  I read 
draft-ietf-dkim-rfc4871bis during the last WGLC in October 2010 and 
commented on the draft ( 
http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ).

IDNA and EAI are not the same.  You are going to break stuff if you 
want to DKIM support for RFC5336bis.  It's up to the DKIM WG to see 
whether it wants to do that or not.

What's unfair is expecting someone else, whether in this working 
group or another working group, to doing the work.  As a matter of 
personal opinion, I see that Murray has been doing a lot of the 
work.  I might not agree with some of the changes he suggested but I 
do not expect him to perform miracles.

Regards,
-sm 

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

---

From: Barry Leiba <[email-masked]>
Date: Sun, 8 May 2011 13:02:10 -0400

I see clear consensus for the text that came out of issue #4, and no
consensus to make a change to support issue #17.  I am closing issue
17 as "wontfix".

Barry, as chair

---

From: Dave CROCKER <[email-masked]>
Date: Sun, 08 May 2011 10:28:23 -0700

> 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.

That would make things go considerably quicker.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 09 May 2011 14:54:11 -0700

On 5/8/11 10:28 AM, Dave CROCKER wrote:
> 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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 9 May 2011 18:41:30 -0400

Doug, issue 17 got no consensus, and is now closed.

Issue 24 is still open and is gathering consensus.  We'll see where it goes.

Please drop discussion of issue 17.

Barry, as chair

---

From: SM <[email-masked]>
Date: Mon, 09 May 2011 16:00:49 -0700

Hi Doug,
>http://trac.tools.ietf.org/wg/dkim/trac/ticket/24

I do not feel strongly about this as it's near the end of this DS 
effort.  This is a friendly note.  Please don't turn it into 
additional work for me. :-)

Section 8 of RFC 4409 mentions that:

   "Any message forwarded or delivered by the MSA MUST conform to the
    requirements of [SMTP-MTA] and [MESSAGE-FORMAT]."

The key in that sentence is the message format.  It may be possible 
to use the above requirement to deal with Issue #24.  With some 
careful wording, you could get away with not introducing any new requirement.

Regards,
-sm