Re: [ietf-dkim] Proposal for new text about multiple header issues
Hector Santos <hsantos@isdg.net> Thu, 04 November 2010 03:57 UTC
Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF523A68D9 for <ietfarch-ietf-dkim-archive@core3.amsl.com>; Wed, 3 Nov 2010 20:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+lbLDvd00KE for <ietfarch-ietf-dkim-archive@core3.amsl.com>; Wed, 3 Nov 2010 20:57:33 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id E8F3A3A68C1 for <ietf-dkim-archive@ietf.org>; Wed, 3 Nov 2010 20:57:33 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [127.0.0.1]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oA43u2tv008594; Wed, 3 Nov 2010 20:56:08 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k00001; t=1288842970; bh=Zzc4wL1xKt3SE/Qpov5stCBEeJA=; h=Message-ID:Date: From:MIME-Version:To:References:In-Reply-To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=NwrR5/33UvqeoFlZK c/DgOWVZSLN7Dyb0OxEWYfu51E2vVp1l7+Wftwn8ulvk+Lf1eH24j3sP2XHQfZBoJhC 1C05GCkAK0x5OHCDwbICs+brGYH/cG0l7WZHdY8JFO558WFBNYVRILNVanKOn37Pc1F J/UZ0f7o2vtNQvzqibrA=
Received: from mail.winserver.com (pop3.winserver.com [208.247.131.9]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id oA43tsK1008588 for <ietf-dkim@mipassoc.org>; Wed, 3 Nov 2010 20:55:59 -0700
Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@isdg.net
Received: by winserver.com (Wildcat! SMTP Router v6.3.453.5) for ietf-dkim@mipassoc.org; Wed, 03 Nov 2010 22:55:30 -0500
Received: from beta.winserver.com (opensite.winserver.com [208.247.131.23]) by winserver.com (Wildcat! SMTP v6.3.453.5) with ESMTP id 3100772984; Wed, 03 Nov 2010 22:55:29 -0500
Received: by beta.winserver.com (Wildcat! SMTP Router v6.3.453.2) for ietf-dkim@mipassoc.org; Wed, 03 Nov 2010 23:54:27 -0400
Received: from [192.168.1.101] ([99.3.147.93]) by beta.winserver.com (Wildcat! SMTP v6.3.453.2) with ESMTP id 841020485; Wed, 03 Nov 2010 23:54:23 -0400
Message-ID: <4CD22EC7.3010209@isdg.net>
Date: Wed, 03 Nov 2010 23:55:51 -0400
From: Hector Santos <hsantos@isdg.net>
Organization: Santronics Software, Inc.
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Charles Lindsey <chl@clerew.man.ac.uk>
References: <F5833273385BB34F99288B3648C4F06F1340E63B42@EXCH-C2.corp.cloudmark.com> <4CC5FB1C.2090804@mail-abuse.org> <F5833273385BB34F99288B3648C4F06F1340E63BB1@EXCH-C2.corp.cloudmark.com> <4CC8D39B.6090205@mail-abuse.org> <4CCBEDE5.3020909@tana.it> <4CCF377A.8030202@mail-abuse.org> <4CD05CBB.70809@tana.it> <op.vlldykbc6hl8nm@clerew.man.ac.uk>
In-Reply-To: <op.vlldykbc6hl8nm@clerew.man.ac.uk>
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [127.0.0.1]); Wed, 03 Nov 2010 20:56:10 -0700 (PDT)
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Wed, 03 Nov 2010 20:56:00 -0700 (PDT)
Cc: DKIM <ietf-dkim@mipassoc.org>
Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
>> ... Apparently, RFC 5617 already >> provides for multiple author addresses. Section 3 reads >> >> If a message has multiple Author Addresses, the ADSP lookups >> SHOULD be performed independently on each address. > > No, that wording applies to multiple addresses in a single From header. If > there are two From headers, ADSP has nothing to say on which to use, so > the expectation is that its implementations will use the first, when asked > to to an ADSP lookup. The whole point of this scam is that big-isp.com > (the Bad Guy in this case) wants to prevent that lookup from ever > happening. As the two specs (DKIM and ADSP) are currently written, his > scam will succeed. Charles, It should be noted that this single 5322.From header with multiple address values scenario was discussed at length in the past with the original SSP draft and the consensus was that SSP checkers should use the first address domain. From the August 2006, SSP draft rev02 draft, section 2.3: http://tools.ietf.org/id/draft-allman-dkim-ssp-02.txt 2.3. Originator Address The "Originator Address" is the email address in the From header field of a message [RFC2822], or if and only if the From header field contains multiple addresses, the first address in the From header field. NON-NORMATIVE RATIONALE: The alternative option when there are multiple addresses in the From header field is to use the value of the Sender header field. This would be closer to the semantics indicated in [RFC2822] than using the first address in the From header field. However, the large number of deployed Mail User Agents that do not display the Sender header field value argues against that. Multiple addresses in the From header field are rare in real life. As noted that this very rare, to cover all security angles regarding a possible domain order relationship of the addresses, IMO, ADSP is technical correct in stating it SHOULD check each domain value. I seem to recall citing a method that can help decide the order of checking the domains using the sender or the signer domain. If the signer domain matches any of the single 5322.from header with multiple domains, it might consider checking this domain policy first with the idea the 1st party signature is more important (trust wise) than a 3rd party domain. It can also use logic to compare the Sender. For example: Sender: tom@domain3.com From: bob@domain1.com, tom@domain3.com, jane@domain2.com, sally@domain4.com DKIM-Signature: d=domain2.com There is reasonable logic here to suggest the domain policy lookup order might be: domain2.com - check for 1st party policy domain3.com - check for a "Sender" policy domain1.com - check remaining in order presented domain4.com > existing ADSP implementations would still get caught. SO we MUST fix it in > DKIM, which IS on our agenda. Technically, in the name of protocol consistency, if there is no DKIM signature, POLICY is still part of the handling framework. This was highlighted in the Threats Analysis (TA) RFC4686 and the SSP Functional Requirements RFC5016 in how it related to failed signature and also 1st party versus 3rd party signatures. Overall, if there was probably one absolute majority consensus among all sides of the policy question, was the solid TA recognition that a valid 1st party signature was a solid reason to short-circuit (skip) a policy lookup. This is codified in RFC5016 section 5.3 item #9: 9. SSP MUST NOT be required to be invoked if a valid first party signature is found. So policy is still active when there is no valid signature. >>> Multiple listings of singleton header fields in the h= parameter is >>> an ugly and wasteful hack that offers an incomplete remedy for >>> these selection conflicts. > > Yes it is ugly but, worse, it does not prevent this particular scam. I don't particular like the kludge, but that should not mean it could not be mentioned as part of the specification as a possible "feature" DKIM API writers or implementors to consider to cover all bases. In other words, the functional spec (ideally) should just mention all the known possible methods software engineers can consider to mitigate the potential exploit. 1 - Integrate DKIM with mail system components that can perform RFC5322 compliance checking with a focus on multiple 5322.From violations. Note: As a new general consideration, all MTA/MUA developers should consider implementing this multiple 5322.From checking, if not done already, as a general practice. 2 - Include specific RFC5322 checking for items that are related to the DKIM verification or signing process. i.e. check for multiple 5322.From headers. 3 - Consider a multiple h=from:from...[:from] N from values to force invalid signatures when N+1 5322.From headers are found. Overall, we should emphasize that all DKIM verifiers SHOULD perform this check or offer an option to check for this specific double 5322.From violation to address integration models where it is not possible for MTA receivers to perform this checking. The above is all I would need as a software person to weigh all design and integration decisions and/or what to make available to operators. For us, we learned that we can best address this a SMTPFILTER-CHECK-RFC5322 filter at our MTA receiver for all inbound messages. Like Murray, I believe this is prudent and the best approach. But unlike Murray, from a generalize protocol standpoint adding DKIM to a product line, I know I can not enforce this method with all MTA systems which may not have the capability or level of software options to do this checking at a MTA. So the DKIM verifier and signer protocol components or API SHOULD also provide a mitigating solution when specific MTA integration models does not provide an answer. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
- Re: [ietf-dkim] Proposal for new text about multi… Alessandro Vesely
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- [ietf-dkim] Proposal for new text about multiple … Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… John Levine
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- Re: [ietf-dkim] Proposal for new text about multi… Mark Delany
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Dave CROCKER
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- Re: [ietf-dkim] Proposal for new text about multi… Hector Santos
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… John Levine
- Re: [ietf-dkim] Proposal for new text about multi… John Levine
- Re: [ietf-dkim] Proposal for new text about multi… Dave CROCKER
- Re: [ietf-dkim] Proposal for new text about multi… Ian Eiloart
- Re: [ietf-dkim] Proposal for new text about multi… Dave CROCKER
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- Re: [ietf-dkim] Proposal for new text about multi… John R. Levine
- Re: [ietf-dkim] Proposal for new text about multi… Steve Atkins
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Ian Eiloart
- Re: [ietf-dkim] Proposal for new text about multi… Charles Lindsey
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- Re: [ietf-dkim] Proposal for new text about multi… Hector Santos
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- Re: [ietf-dkim] Proposal for new text about multi… Alessandro Vesely
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- Re: [ietf-dkim] Proposal for new text about multi… Alessandro Vesely
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- Re: [ietf-dkim] Proposal for new text about multi… Charles Lindsey
- Re: [ietf-dkim] Proposal for new text about multi… Alessandro Vesely
- Re: [ietf-dkim] Proposal for new text about multi… John R. Levine
- Re: [ietf-dkim] Proposal for new text about multi… Douglas Otis
- [ietf-dkim] The Total Solution is an Integrated O… Hector Santos
- Re: [ietf-dkim] Proposal for new text about multi… Hector Santos
- Re: [ietf-dkim] Proposal for new text about multi… Alessandro Vesely
- Re: [ietf-dkim] The Total Solution is an Integrat… Hector Santos
- Re: [ietf-dkim] Proposal for new text about multi… Murray S. Kucherawy
- Re: [ietf-dkim] Proposal for new text about multi… Hector Santos
- Re: [ietf-dkim] Necessary Verifier Actions to mit… Douglas Otis
- Re: [ietf-dkim] Necessary Verifier Actions to mit… Charles Lindsey