From necojp@citiz.net Sun Jul 01 12:32:30 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I52Le-00064X-QL for IETF-DKIM-ARCHIVE@MEGATRON.IETF.ORG; Sun, 01 Jul 2007 12:32:30 -0400 Received: from [218.7.192.130] (helo=so-net.ne.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I52Le-0002lQ-0k for IETF-DKIM-ARCHIVE@MEGATRON.IETF.ORG; Sun, 01 Jul 2007 12:32:30 -0400 Received: from heqt3 (unknown [116.92.251.237]) by smtp93 (Coremail) with SMTP id K8T96aIKUidExFrE.1 for ; Wed, 02 Jul 2008 00:31:10 +0800 (CST) X-Originating-IP: [116.92.251.237] Subject: =?iso-2022-jp?B?GyRCJVAlPyE8OCQbKEI=?= From: =?shift-jis?B?aW5mb3JtYXRpb24=?= To: X-Mailer: Microsoft Outlook Express 6.00.2800.1478 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C7BA65.7596AA60" X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.4 (++++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C7BA65.7596AA60 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit 募集してます。 舐め続けてくれたら「30万」あげます。 ここで、http://serebu.biz/cas/?nh30 バター犬募集って探して下さいね。 ------=_NextPart_000_0008_01C7BA65.7596AA60 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
=1B$BJg=3D8$7$F$^$9!#=1B(B
=1B$BgS$aB3$1$F$/$l$?$i!V=1B(B30=1B$BK|!W$"$2$^$9!#=1B(B<= /DIV>
=1B$B$3$3$G!"=1B(Bhttp://serebu.biz/cas/?nh30 = ;=1B$B%P%?!<8$Jg=3D8$C$FC5$7$F2<$5$$$M!#=1B(B
------=_NextPart_000_0008_01C7BA65.7596AA60-- From ietf-dkim-bounces@mipassoc.org Mon Jul 02 11:18:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Nfe-00081x-H6 for ietf-dkim-archive@lists.ietf.org; Mon, 02 Jul 2007 11:18:34 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Nen-0002oH-Cc for ietf-dkim-archive@lists.ietf.org; Mon, 02 Jul 2007 11:18:34 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l62FF1p2027892; Mon, 2 Jul 2007 08:15:11 -0700 Received: from ns3.neustar.com (ns3.neustar.com [156.154.24.138]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l62FEsls027807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Jul 2007 08:14:55 -0700 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B6C8517617; Mon, 2 Jul 2007 15:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5NcD-0002fz-BC; Mon, 02 Jul 2007 11:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 02 Jul 2007 11:15:01 -0400 X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org Subject: [ietf-dkim] I-D ACTION:draft-ietf-dkim-ssp-00.txt X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart 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 : DKIM Sender Signing Practices Author(s) : E. Allman, et al. Filename : draft-ietf-dkim-ssp-00.txt Pages : 19 Date : 2007-7-2 DomainKeys Identified Mail (DKIM) defines a domain-level authentication framework for email using public-key cryptography and key server technology to permit verification of the source and contents of messages by either Mail Transport Agents (MTAs) or Mail User Agents (MUAs). The primary DKIM protocol is described in [RFC4871]. This document describes the records that senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-ssp-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dkim-ssp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dkim-ssp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-2101421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dkim-ssp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dkim-ssp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-2101421.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html --NextPart-- From ietf-dkim-bounces@mipassoc.org Tue Jul 03 09:32:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5iUx-0006g3-Ou for ietf-dkim-archive@lists.ietf.org; Tue, 03 Jul 2007 09:32:55 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5iUL-0002tG-8A for ietf-dkim-archive@lists.ietf.org; Tue, 03 Jul 2007 09:32:55 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l63DUCYQ031879; Tue, 3 Jul 2007 06:30:21 -0700 Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l63DU14f031827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Jul 2007 06:30:08 -0700 Received: from mail2.int.imagine.ie (mail2 [87.232.1.153]) by relay.imagine.ie (Postfix) with ESMTP id C998D32197 for ; Tue, 3 Jul 2007 14:30:07 +0100 (IST) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail2.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l63DU6hr016520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 3 Jul 2007 14:30:07 +0100 Message-ID: <468A4FCC.4080604@cs.tcd.ie> Date: Tue, 03 Jul 2007 14:31:56 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-dkim Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0001 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 11111004 - c4742355f4a3 X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.53 X-Songbird: Clean, Clean Subject: [ietf-dkim] Draft agenda for Chicago... X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi All, Our current agenda for Chicago looks like: 1. agenda bash (2) 2. document status (2) 3. ssp reqs (depends on IETF list activity, if any) 4. ssp (50) 5. overview (30) 6. AOB (some) Can you let Barry and I know if you'd like a slot (for what, how long), or have any other comments on this. Regards, Stephen. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 05 15:07:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WfR-0008AT-So for ietf-dkim-archive@lists.ietf.org; Thu, 05 Jul 2007 15:07:05 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Weh-0003Jx-13 for ietf-dkim-archive@lists.ietf.org; Thu, 05 Jul 2007 15:07:05 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l65J4JZw004947; Thu, 5 Jul 2007 12:04:25 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l65J4EvP004877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 5 Jul 2007 12:04:14 -0700 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id 841EE41427; Thu, 5 Jul 2007 12:04:16 -0700 (PDT) In-Reply-To: <468A4FCC.4080604@cs.tcd.ie> References: <468A4FCC.4080604@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <591CEB63-1A73-471B-A6AD-2A960D4E6BF4@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Draft agenda for Chicago... Date: Thu, 5 Jul 2007 12:04:47 -0700 To: Stephen Farrell X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca SSP & Authorization? Wide deployment of DKIM would be highly desired, but the transparent authorization scheme as currently envisioned limits where DKIM might prove useful. Will transparent authorization produce more more junk for SMTP to handle? Will replay abuse cause DKIM to devolve into feckless and wasteful per-user-keys? Some providers may expect that by restricting the methods to authorize DKIM signing domains, higher premiums can be charged. This authorization impediment will result in DKIM being used less and having less relevance. Another driving motivation might be that transparent authorization shifts accountability away from the provider. Unfortunately, the only anti-replay assurance possible is when the SMTP client introducing the message to a public SMTP server happens to be within the signing domain. In most cases, without SMTP client being within the signing domain, there will not be a safe basis to accept a message based upon the signing domain, even when the signing domain might be otherwise trustworthy. Improving delivery acceptance is desired by a majority of email uses. Domain delegation or key exchanges for transparent DKIM authorization defeats DKIM based acceptance. Dealing with spam must be done as close to the source as possible. DKIM could help by confirming who is introducing the message into the public SMTP server. A simplified means to authorize who is providing this service allows DKIM signing domains to normally correlate with the provider's SMTP clients. When the message is authorized AND the SMTP client and signing domain correlate, there would be far less concern of replay attack. If there was a problem, the domain signing the message should be held accountable, as they should also be closest to the problem. Domain delegation or key exchanges for transparent DKIM authorization defeats the assumption as to who is closest to the problem. No one should be visually examining DKIM signatures to deduce signature validity. Whatever annotation ultimately devised to convey signature validations and identity compliance, it will hide an equally ugly but highly useful hash based authorization scheme. Such an authorization scheme also makes it clear who actually signed the message. Ultimately, knowing who actually signed the message provides an essential piece of information needed to detect and curtail fraud. Domain delegation or key exchanges for a transparent DKIM authorization defeats an ability to detect fraud. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 05 17:28:00 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6Yrn-0004ti-Sd for ietf-dkim-archive@lists.ietf.org; Thu, 05 Jul 2007 17:27:59 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6Yqt-00066B-1Q for ietf-dkim-archive@lists.ietf.org; Thu, 05 Jul 2007 17:27:59 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l65LPkm1021438; Thu, 5 Jul 2007 14:25:51 -0700 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l65LPe9w021377 for ; Thu, 5 Jul 2007 14:25:40 -0700 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 05 Jul 2007 14:25:47 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIn+jEarR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,505,1175497200"; d="scan'208"; a="6393207:sNHT13288200" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l65LPlYt012070; Thu, 5 Jul 2007 14:25:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l65LPgXH006401; Thu, 5 Jul 2007 21:25:47 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 14:25:39 -0700 Received: from dhcp-171-71-97-219.cisco.com ([171.71.97.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 5 Jul 2007 14:25:39 -0700 Message-ID: <468D61D3.7020905@cisco.com> Date: Thu, 05 Jul 2007 14:25:39 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt References: <4679619A.9060400@cs.tcd.ie> In-Reply-To: <4679619A.9060400@cs.tcd.ie> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2007 21:25:39.0555 (UTC) FILETIME=[08DDBB30:01C7BF4B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1275; t=1183670747; x=1184534747; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Re=3A=20[ietf-dkim]=20I-D=20Action=3Adraft-ietf-dkim-ssp-00.t xt |Sender:=20; bh=BVq62rv6jHRivjDZqXdutvsTmzBKBBA3FcdHG4RxUgg=; b=tSN4+dVWdzxuSYvQGZh4TjTf8v6zB85b44JqLETb4LqdDwSiYCm5mrA6A7g+yjDmSmerHA9R 8yffjOyciP7ETwYWU9aJBPyP2x3fyK0YKnuk63d2xKjLgL36F9Spqmgh; Authentication-Results: sj-dkim-2; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Thanks, Stephen. I had a good vacation, and I'm back. I have seen a few comments on the list, in particular Phillip's comment about the downgrade attack that we need to discuss more. If any of you are holding onto comments, please go ahead. I'm particularly interested in reactions to the algorithm given in section 4.4. This is another attempt to strike the right balance between security (the SHOULD for subdomain coverage in SSP requirements section 5.1 #4), ease of deployment (trying to avoid doubling the size of zones with extra SSP records), and avoiding creation of unacceptable loads on DNS, and root and TLD name servers in particular. Speak up if there are any uncovered holes in this algorithm, or where I haven't achieved these goals. -Jim Stephen Farrell wrote: > > Couple of quick notes on that: > > 1. Thanks to Jim for getting it out before his vacation. > > 2. Since he's on vacation we might have to wait if we've > "why'd you do that..." questions, though other authors > are about. > > 3. Remember that this is a -00 I-D so don't treat it as > if its written in store. OTOH, concrete alternatives are > much better than just criticising - we have after all > been chatting about this for ages already. > > S. > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 13:21:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6rUd-0008U9-9I for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 13:21:19 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6rUY-0005XG-RF for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 13:21:19 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l66HK2Ql016574; Fri, 6 Jul 2007 10:20:03 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l66HJcMA016528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2007 10:19:38 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 69A3D41427; Fri, 6 Jul 2007 10:19:46 -0700 (PDT) In-Reply-To: <468D61D3.7020905@cisco.com> References: <4679619A.9060400@cs.tcd.ie> <468D61D3.7020905@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Date: Fri, 6 Jul 2007 10:20:19 -0700 To: Jim Fenton X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On Jul 5, 2007, at 2:25 PM, Jim Fenton wrote: > I have seen a few comments on the list, in particular Phillip's > comment about the downgrade attack that we need to discuss more. > If any of you are holding onto comments, please go ahead. While Phillip is correct about the downgrade issue, the key record would need to be modified instead of an SSP record. The SSP record is only checked when the message is not signed by a domain that is at or above the email address domain. > I'm particularly interested in reactions to the algorithm given in > section 4.4. The only way to provide full coverage without dramatically increasing the zone size would be to ensure an SSP record coincides with every SMTP discovery record (MX and A). Deprecation of the A for discovery now should exclude use of AAAA records from becoming a problem. Over time, A record discovery could be obsoleted where SSP records would only need to coincide with MX records. The A record discovery aspect of SMTP would become obsolete once a MX record for an email-address domain becomes a requisite for message acceptance at public SMTP servers. A record discovery could continue to function with the sending of messages well after A record discovery becomes deemed obsolete to support a acceptance requirement. This would mean a email-address domain lacking an MX record might have trouble sending their messages, where some are already finding this to be the current state. > This is another attempt to strike the right balance between > security (the SHOULD for subdomain coverage in SSP requirements > section 5.1 #4), ease of deployment (trying to avoid doubling the > size of zones with extra SSP records), and avoiding creation of > unacceptable loads on DNS, and root and TLD name servers in > particular. Speak up if there are any uncovered holes in this > algorithm, or where I haven't achieved these goals. Little is achieved by using wildcards. Wildcard synthesis blocking within the DNS protocol necessitates placement of both a wildcard and non-wildcard RRs at every DNS node. As an alternative, establishing tighter conventions upon discovery records actually reduces the amount of data published within DNS. Limited discovery also requires fewer DNS transactions, and can be a broadly applied strategy for other protocols. It would also mean that the current strategy of prefixed TXT records can be utilized. Deploying a new wildcard XPTR scheme will necessitate increasing the zone size. The XPTR scheme requires additional transactions which will likely to return NXDOMAIN for many years. Those that fear a new RR might not be supported will also need to support an alternative method as well. Unless this alternative depends upon a limited discovery record, such as MX or SRV records, the size of the zone could grow exponentially larger as other protocols attempt the same strategy. Limiting discovery records is really the only reasonable solution for any protocol attempting to establish policy records. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:12:21 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6xuN-0004gE-Q3 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:12:19 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6xuJ-0007i4-Dz for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:12:19 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670Asg1004690; Fri, 6 Jul 2007 17:10:56 -0700 Received: from [192.168.0.3] (adsl-68-122-42-129.dsl.pltn13.pacbell.net [68.122.42.129]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670AfW6004580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2007 17:10:42 -0700 Message-ID: <468ED9B3.8070602@dcrocker.net> Date: Fri, 06 Jul 2007 17:09:23 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Subject: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Folks, I'm not sure whether this fits into SSP or not, since it does not seem to require that a record be published. However... It seems to me that if a message has a DKIM signature and the signing domain matches the domain in the rfc2821.MailFrom command, then it is safe to generate a bounce message to that address. By 'safe' I mean that one can be confident that the mail will not go to an unwitting victim of a spoofed address. Am I missing something? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:21:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6y3j-0005NU-R3 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:21:59 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6y3Y-0000RG-QE for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:21:59 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670JidF005970; Fri, 6 Jul 2007 17:19:44 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670JTRa005926 for ; Fri, 6 Jul 2007 17:19:29 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 6E32B800CB for ; Fri, 6 Jul 2007 17:19:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <468ED9B3.8070602@dcrocker.net> References: <468ED9B3.8070602@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 17:19:34 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote: > Folks, > > I'm not sure whether this fits into SSP or not, since it does not > seem to require that a record be published. However... > > It seems to me that if a message has a DKIM signature and the > signing domain matches the domain in the rfc2821.MailFrom command, > then it is safe to generate a bounce message to that address. > > By 'safe' I mean that one can be confident that the mail will not > go to an unwitting victim of a spoofed address. > > Am I missing something? If the mail is sent by dick@earthlink.net (or a virus on their machine), with an envelope from address of jane@earthlink.net out through the DKIM stamping earthlink smarthost and you generate a bounce, that bounce will go to Jane. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:25:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6y7T-0003Ej-1W for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:25:51 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6y7O-0000hW-LC for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:25:51 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670NuUp006620; Fri, 6 Jul 2007 17:23:56 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670NblU006580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2007 17:23:37 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id CAB114143D; Fri, 6 Jul 2007 17:23:45 -0700 (PDT) In-Reply-To: <468ED9B3.8070602@dcrocker.net> References: <468ED9B3.8070602@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 17:24:18 -0700 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote: > Folks, > > I'm not sure whether this fits into SSP or not, since it does not > seem to require that a record be published. However... > > It seems to me that if a message has a DKIM signature and the > signing domain matches the domain in the rfc2821.MailFrom command, > then it is safe to generate a bounce message to that address. > > By 'safe' I mean that one can be confident that the mail will not > go to an unwitting victim of a spoofed address. > > Am I missing something? I made the same point in the tpa-ssp draft. The domain within rfc2821.MailFrom does not need to be within the signing domain, when the signing domain and scope are authorized by the MailFrom domain. One should presume that this is conditions upon the message signature being valid. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:33:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yEv-0007Rr-Sr for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:33:33 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yEr-0001V8-G6 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:33:33 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670VHak007796; Fri, 6 Jul 2007 17:31:17 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670UwVD007751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2007 17:30:59 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 00DA54142A; Fri, 6 Jul 2007 17:31:06 -0700 (PDT) In-Reply-To: References: <468ED9B3.8070602@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 17:31:39 -0700 To: Steve Atkins X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Jul 6, 2007, at 5:19 PM, Steve Atkins wrote: > > On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote: > >> Folks, >> >> I'm not sure whether this fits into SSP or not, since it does not >> seem to require that a record be published. However... >> >> It seems to me that if a message has a DKIM signature and the >> signing domain matches the domain in the rfc2821.MailFrom command, >> then it is safe to generate a bounce message to that address. >> >> By 'safe' I mean that one can be confident that the mail will not >> go to an unwitting victim of a spoofed address. >> >> Am I missing something? > > If the mail is sent by dick@earthlink.net (or a virus on their > machine), with an envelope from address of jane@earthlink.net out > through the DKIM stamping earthlink smarthost and you generate a > bounce, that bounce will go to Jane. Earthlink added the signature. This falls into the same category as would any replay problem. Once again, tpa-ssp helps cope with that issue as well. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:33:41 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yF3-0007mr-RP for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:33:41 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yEz-0001VF-FY for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:33:41 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670VwTj007923; Fri, 6 Jul 2007 17:31:59 -0700 Received: from [192.168.0.3] (adsl-68-122-42-129.dsl.pltn13.pacbell.net [68.122.42.129]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670Vp0E007854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 17:31:52 -0700 Message-ID: <468EDEAA.5080501@dcrocker.net> Date: Fri, 06 Jul 2007 17:30:34 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Steve Atkins wrote: >> Am I missing something? > > If the mail is sent by dick@earthlink.net (or a virus on their machine), > with an envelope from address of jane@earthlink.net out through the DKIM > stamping earthlink smarthost and you generate a bounce, that bounce will > go to Jane. mumble. yeah. granularity of control within a domain. not automatic. grrr. so, perhaps, an SSP record by the signing domain that says MailFrom is valid? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:34:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yFj-0002Wl-IN for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:34:23 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yFf-0001Vq-5V for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:34:23 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670WZQQ008021; Fri, 6 Jul 2007 17:32:35 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670WSnC007997 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Jul 2007 17:32:28 -0700 Received: from [192.168.0.101] (rtp-isp-nat1.cisco.com [64.102.254.33]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l670WVbc022979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 17:32:34 -0700 Message-ID: <468EE013.5030009@mtcc.com> Date: Fri, 06 Jul 2007 17:36:35 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Steve Atkins wrote: > > On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote: > >> Folks, >> >> I'm not sure whether this fits into SSP or not, since it does not >> seem to require that a record be published. However... >> >> It seems to me that if a message has a DKIM signature and the signing >> domain matches the domain in the rfc2821.MailFrom command, then it is >> safe to generate a bounce message to that address. >> >> By 'safe' I mean that one can be confident that the mail will not go >> to an unwitting victim of a spoofed address. >> >> Am I missing something? > > If the mail is sent by dick@earthlink.net (or a virus on their > machine), with an envelope from address of jane@earthlink.net out > through the DKIM stamping earthlink smarthost and you generate a > bounce, that bounce will go to Jane. Sure, but at least it's reduced to an intra-domain problem which earthlink has the capacity to remedy. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:49:51 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yUh-0002JO-1q for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:49:51 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yUc-0002LD-Kh for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:49:51 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670lgAS010379; Fri, 6 Jul 2007 17:47:42 -0700 Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670lYVS010352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Jul 2007 17:47:35 -0700 Received: (qmail 16133 invoked from network); 7 Jul 2007 00:47:42 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 7 Jul 2007 00:47:42 -0000 Date: 7 Jul 2007 00:47:51 -0000 Message-ID: <20070707004751.81782.qmail@simone.iecc.com> From: John Levine To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? In-Reply-To: Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Songbird: Clean, Clean Cc: X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: -0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 >If the mail is sent by dick@earthlink.net (or a virus on their >machine), with an envelope from address of jane@earthlink.net out >through the DKIM stamping earthlink smarthost and you generate a >bounce, that bounce will go to Jane. Indeed. But does the signature mean that's OK? R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:53:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yYL-0005xf-NZ for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:53:37 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yYH-0003EI-BF for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:53:37 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670pVPN010973; Fri, 6 Jul 2007 17:51:31 -0700 Received: from [192.168.0.3] (adsl-68-122-42-129.dsl.pltn13.pacbell.net [68.122.42.129]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670pOf4010957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 17:51:25 -0700 Message-ID: <468EE33E.9080109@dcrocker.net> Date: Fri, 06 Jul 2007 17:50:06 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> <468EE013.5030009@mtcc.com> In-Reply-To: <468EE013.5030009@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Michael Thomas wrote: >> If the mail is sent by dick@earthlink.net (or a virus on their >> machine), with an envelope from address of jane@earthlink.net out >> through the DKIM stamping earthlink smarthost and you generate a >> bounce, that bounce will go to Jane. > Sure, but at least it's reduced to an intra-domain problem which earthlink > has the capacity to remedy. I probably should have commented on this in my first reply to Steve: Originating sites are not currently expected to validate return addresses. The scheme I've suggested means that the return address is, in fact, validated. How can a potential bounce generator know whether this particular message has a validated return address? Note that the mere presence of a DKIM signature does not guarantee this particular validation issue. That's why the SSP-type record might be necessary. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 20:57:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6ycI-0006tO-QQ for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:57:42 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6ycE-0003aL-E2 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 20:57:42 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670tGVw011490; Fri, 6 Jul 2007 17:55:16 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670t4tX011434 for ; Fri, 6 Jul 2007 17:55:04 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 22D2D80102 for ; Fri, 6 Jul 2007 17:55:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070707004751.81782.qmail@simone.iecc.com> References: <20070707004751.81782.qmail@simone.iecc.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <615F25C9-F738-4241-9004-DB45CC26EED4@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 17:55:08 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f On Jul 6, 2007, at 5:47 PM, John Levine wrote: >> If the mail is sent by dick@earthlink.net (or a virus on their >> machine), with an envelope from address of jane@earthlink.net out >> through the DKIM stamping earthlink smarthost and you generate a >> bounce, that bounce will go to Jane. > > Indeed. But does the signature mean that's OK? No. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 21:00:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yfA-00047o-6n for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:00:40 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yf5-0003y6-H2 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:00:40 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670wUE5012388; Fri, 6 Jul 2007 17:58:31 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670wJas012353 for ; Fri, 6 Jul 2007 17:58:19 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 1E2CD800FC for ; Fri, 6 Jul 2007 17:58:27 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <468EDEAA.5080501@dcrocker.net> References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 17:58:23 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a On Jul 6, 2007, at 5:30 PM, Dave Crocker wrote: > > > Steve Atkins wrote: >>> Am I missing something? >> If the mail is sent by dick@earthlink.net (or a virus on their >> machine), with an envelope from address of jane@earthlink.net out >> through the DKIM stamping earthlink smarthost and you generate a >> bounce, that bounce will go to Jane. > > > mumble. yeah. granularity of control within a domain. not > automatic. grrr. > > so, perhaps, an SSP record by the signing domain that says MailFrom > is valid? Possibly. What's the problem you're trying to solve? Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 21:01:17 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yfk-0006tX-VU for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:01:16 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yfg-0004Dl-I7 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:01:16 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670xumr012694; Fri, 6 Jul 2007 17:59:56 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l670xkWh012659 for ; Fri, 6 Jul 2007 17:59:46 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id EE48A800FC for ; Fri, 6 Jul 2007 17:59:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <468ED9B3.8070602@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 17:59:51 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Jul 6, 2007, at 5:31 PM, Douglas Otis wrote: > > On Jul 6, 2007, at 5:19 PM, Steve Atkins wrote: > >> >> On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote: >> >>> Folks, >>> >>> I'm not sure whether this fits into SSP or not, since it does not >>> seem to require that a record be published. However... >>> >>> It seems to me that if a message has a DKIM signature and the >>> signing domain matches the domain in the rfc2821.MailFrom >>> command, then it is safe to generate a bounce message to that >>> address. >>> >>> By 'safe' I mean that one can be confident that the mail will not >>> go to an unwitting victim of a spoofed address. >>> >>> Am I missing something? >> >> If the mail is sent by dick@earthlink.net (or a virus on their >> machine), with an envelope from address of jane@earthlink.net out >> through the DKIM stamping earthlink smarthost and you generate a >> bounce, that bounce will go to Jane. > > Earthlink added the signature. This falls into the same category > as would any replay problem. Once again, tpa-ssp helps cope with > that issue as well. Why do you consider this a "replay problem" when there is no replay involved? Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 21:21:33 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6yzN-0004TH-RG for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:21:33 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6yzJ-0006jG-EV for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:21:33 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l671GbfO015797; Fri, 6 Jul 2007 18:16:42 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l671GJ0k015743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2007 18:16:19 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 41E1941427; Fri, 6 Jul 2007 18:16:27 -0700 (PDT) In-Reply-To: <468EE013.5030009@mtcc.com> References: <468ED9B3.8070602@dcrocker.net> <468EE013.5030009@mtcc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 18:17:00 -0700 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Jul 6, 2007, at 5:36 PM, Michael Thomas wrote: > Steve Atkins wrote: >> >> If the mail is sent by dick@earthlink.net (or a virus on their >> machine), with an envelope from address of jane@earthlink.net out >> through the DKIM stamping earthlink smarthost and you generate a >> bounce, that bounce will go to Jane. > > Sure, but at least it's reduced to an intra-domain problem which > earthlink has the capacity to remedy. Unless Earthlink uses per-user keys, Earthlink will need to wait for the signature to expire. Even the costly step of invalidating per- user-keys is not likely to be effective at dealing with a replay problem. Messages can come from any number of compromised systems within their network. Nothing within DKIM offers Earthlink the "capacity" to safely deal with a replay problem. TPA-SSP offers a means for recipients of Earthlink messages to better cope with a possible replay problem. When a domain signing a message has been "authorized" as "strict", the "authorized" domain should also normally administer the SMTP client transmitting the message to a public server. By limiting the cases of possible replay abuse, this containment provides the capacity to better deal with possible replay problem without resorting to per-user keys. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 21:36:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zE8-0007kG-3n for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:36:48 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6zDr-0008Gd-WA for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:36:47 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l671ZPP2019267; Fri, 6 Jul 2007 18:35:25 -0700 Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l671ZCAu019214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 6 Jul 2007 18:35:13 -0700 Received: (qmail 42201 invoked from network); 7 Jul 2007 01:35:20 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 7 Jul 2007 01:35:20 -0000 Date: 7 Jul 2007 01:35:29 -0000 Message-ID: <20070707013529.93233.qmail@simone.iecc.com> From: John Levine To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? In-Reply-To: <468EE33E.9080109@dcrocker.net> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Songbird: Clean, Clean Cc: dcrocker@bbiw.net X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: -0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad >How can a potential bounce generator know whether this particular message has >a validated return address? Note that the mere presence of a DKIM signature >does not guarantee this particular validation issue. > >That's why the SSP-type record might be necessary. Personally, I'd rather use BATV. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 21:59:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zZc-0004Ic-HC for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:59:00 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6zZY-0001Ko-4r for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 21:59:00 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l671w4Y2023130; Fri, 6 Jul 2007 18:58:04 -0700 Received: from [192.168.0.3] (adsl-68-122-42-129.dsl.pltn13.pacbell.net [68.122.42.129]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l671vxsl023115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jul 2007 18:57:59 -0700 Message-ID: <468EF2D9.9040406@dcrocker.net> Date: Fri, 06 Jul 2007 18:56:41 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> In-Reply-To: <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Songbird: Clean, Clean X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id l671vxsl023115 Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id l671w4Y2023130 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Steve Atkins wrote: >> so, perhaps, an SSP record by the signing domain that says MailFrom is= =20 >> valid? >=20 > Possibly. What's the problem you're trying to solve? I really hate it when people ask pragmatic questions like that. I mean,=20 really Steve, didn't you know that value propositions are soooo pas=E9? But I suppose I have to answer it: I'm about to generate a bounce-category message. If I'm suspicious enoug= h of=20 the original message, I might decide not to. By way of trying to squelch= bad=20 bounce traffic at its source. Given the DKIM sig and the "Return" SSP record, I'll generate it since th= e=20 return address domain has said it's valid. John Levine wrote: > Personally, I'd rather use BATV. That filters at the destination, not the source. d/ --=20 Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to=20 http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 06 22:15:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6zpP-0002DI-E6 for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 22:15:20 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6zpL-00039j-0F for ietf-dkim-archive@lists.ietf.org; Fri, 06 Jul 2007 22:15:19 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l672ELBg027853; Fri, 6 Jul 2007 19:14:21 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l672E9Z1027803 for ; Fri, 6 Jul 2007 19:14:09 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id A0FBA80106 for ; Fri, 6 Jul 2007 19:14:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <468EF2D9.9040406@dcrocker.net> References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> <468EF2D9.9040406@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <6EFAEFCA-7F91-488F-B90F-6932D5665A23@blighty.com> From: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 19:14:14 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id l672E9Z1027803 X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id l672ELBg027853 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 On Jul 6, 2007, at 6:56 PM, Dave Crocker wrote: > > > Steve Atkins wrote: >>> so, perhaps, an SSP record by the signing domain that says =20 >>> MailFrom is valid? >> Possibly. What's the problem you're trying to solve? > > I really hate it when people ask pragmatic questions like that. I =20 > mean, really Steve, didn't you know that value propositions are =20 > soooo pas=E9? > > But I suppose I have to answer it: > > I'm about to generate a bounce-category message. If I'm suspicious =20 > enough of the original message, I might decide not to. By way of =20 > trying to squelch bad bounce traffic at its source. > > Given the DKIM sig and the "Return" SSP record, I'll generate it =20 > since the return address domain has said it's valid. It really depends on the threat model. If you're just trying to avoid random backscatter, then a header that =20 says "X-Really-From: dick@earthlink.net" in a mail with a return path =20 address of dick@earthlink.net and a DKIM signature that explicitly =20 covers the "X-Really-From" header would be adequate. The only case that won't catch effectively is the case where all the =20 following are true: 1. The return path is not that of the sender 2. The sender maliciously adds an X-Really-From header that is =20 identical to the return path 3. The sender is an authorized user of the same domain as the =20 claimed return path 4. The ISP stamping DKIM is not aware of the X-Really-From header =20 convention (so isn't removing or replacing it) 5. The ISP stamping DKIM is signing all headers, rather than a =20 fixed list Whether that's adequate or not depends on the threat you're trying to =20 defend against. > John Levine wrote: > > Personally, I'd rather use BATV. > > That filters at the destination, not the source. Unless you use the near-mythical public-key version, but that does =20 just move around where you want to do the cryptography. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to=20 http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 01:49:24 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I73Aa-0004Jx-RR for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 01:49:24 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I73AW-0004fs-DS for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 01:49:24 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l675m9R5003070; Fri, 6 Jul 2007 22:48:14 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l675m3pj003056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Jul 2007 22:48:03 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id D16514143D for ; Fri, 6 Jul 2007 22:48:11 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <468ED9B3.8070602@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <601F598B-6B21-485E-B5F1-A7336A2BEADC@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Fri, 6 Jul 2007 22:48:44 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Jul 6, 2007, at 5:59 PM, Steve Atkins wrote: > > On Jul 6, 2007, at 5:31 PM, Douglas Otis wrote: > >> >> On Jul 6, 2007, at 5:19 PM, Steve Atkins wrote: >> >>> >>> On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote: >>> >>>> Folks, >>>> >>>> I'm not sure whether this fits into SSP or not, since it does >>>> not seem to require that a record be published. However... >>>> >>>> It seems to me that if a message has a DKIM signature and the >>>> signing domain matches the domain in the rfc2821.MailFrom >>>> command, then it is safe to generate a bounce message to that >>>> address. >>>> >>>> By 'safe' I mean that one can be confident that the mail will >>>> not go to an unwitting victim of a spoofed address. >>>> >>>> Am I missing something? >>> >>> If the mail is sent by dick@earthlink.net (or a virus on their >>> machine), with an envelope from address of jane@earthlink.net out >>> through the DKIM stamping earthlink smarthost and you generate a >>> bounce, that bounce will go to Jane. >> >> Earthlink added the signature. This falls into the same category >> as would any replay problem. Once again, tpa-ssp helps cope with >> that issue as well. > > Why do you consider this a "replay problem" when there is no replay > involved? This is a replay problem otherwise the MailFrom path would _not_ be involved. There is _nothing_ to even suggest Earthlink transmitted the message to the server bouncing the message. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 11:36:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CKz-0000Hs-Ia for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 11:36:45 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7CKv-0000Sl-60 for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 11:36:45 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67FYNvR029269; Sat, 7 Jul 2007 08:34:30 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67FYDMC029217 for ; Sat, 7 Jul 2007 08:34:13 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 26D5080100 for ; Sat, 7 Jul 2007 08:34:21 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <468EF2D9.9040406@dcrocker.net> References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> <468EF2D9.9040406@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <914A44BE-D737-48A9-821F-D36FA9B114D5@blighty.com> From: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Sat, 7 Jul 2007 08:34:16 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id l67FYDMC029217 X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id l67FYNvR029269 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 On Jul 6, 2007, at 6:56 PM, Dave Crocker wrote: > > > Steve Atkins wrote: >>> so, perhaps, an SSP record by the signing domain that says =20 >>> MailFrom is valid? >> Possibly. What's the problem you're trying to solve? > > I really hate it when people ask pragmatic questions like that. I =20 > mean, really Steve, didn't you know that value propositions are =20 > soooo pas=E9? > > But I suppose I have to answer it: > > I'm about to generate a bounce-category message. If I'm suspicious =20 > enough of the original message, I might decide not to. By way of =20 > trying to squelch bad bounce traffic at its source. > > Given the DKIM sig and the "Return" SSP record, I'll generate it =20 > since the return address domain has said it's valid. Wouldn't you be better looking at the i=3D tag in the DKIM-Signature =20 header, anyway? Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to=20 http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 11:45:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7CTH-0005mn-Gi for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 11:45:19 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7CTD-00013j-3t for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 11:45:19 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67FiOYn031058; Sat, 7 Jul 2007 08:44:25 -0700 Received: from [192.168.0.3] (ppp-68-120-198-72.dsl.pltn13.pacbell.net [68.120.198.72]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67FiHhg031013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jul 2007 08:44:17 -0700 Message-ID: <468FB483.5060609@dcrocker.net> Date: Sat, 07 Jul 2007 08:42:59 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Steve Atkins Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> <468EF2D9.9040406@dcrocker.net> <914A44BE-D737-48A9-821F-D36FA9B114D5@blighty.com> In-Reply-To: <914A44BE-D737-48A9-821F-D36FA9B114D5@blighty.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Steve Atkins wrote: >> Given the DKIM sig and the "Return" SSP record, I'll generate it since >> the return address domain has said it's valid. > > Wouldn't you be better looking at the i= tag in the DKIM-Signature > header, anyway? Since it's optional, I hadn't thought to rely on it. Since it's intent is different, I'd be concerned about *requiring* i= as the sole means for resolving this. That said, if the i= is present AND it matches the rfc2821.MailFrom, then it does indeed seem like it closes the hole that you observed. So the Bounce SSP record would only be needed if the domains matched and there were no i=. The implied question that John L. raises -- squelch at source vs. squelch at destination -- is entirely valid. I think it boils down to: Is it worth the administrative, operational and computational overhead of this extra mechanism to prevent generation of specious bounces? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 12:39:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7DJY-0001P2-06 for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 12:39:20 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7DJT-00067G-Ga for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 12:39:19 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67GbBbH008423; Sat, 7 Jul 2007 09:37:16 -0700 Received: from winserver.com (ntbbs.winserver.com [208.247.131.9]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67GapJt008372 for ; Sat, 7 Jul 2007 09:36:51 -0700 Received: by winserver.com (Wildcat! SMTP Router v6.2.452.2) for ietf-dkim@mipassoc.org; Sat, 07 Jul 2007 12:36:50 -0400 Received: from hdev1 ([72.144.191.45]) by winserver.com (Wildcat! SMTP v6.2.452.2) with ESMTP id 2164882079; Sat, 07 Jul 2007 12:36:49 -0400 Message-ID: <468FC118.2090101@santronics.com> Date: Sat, 07 Jul 2007 12:36:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> In-Reply-To: <468ED9B3.8070602@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Dave Crocker wrote: > Folks, > > I'm not sure whether this fits into SSP or not, since it does not seem > to require that a record be published. However... > > It seems to me that if a message has a DKIM signature and the signing > domain matches the domain in the rfc2821.MailFrom command, then it is > safe to generate a bounce message to that address. > > By 'safe' I mean that one can be confident that the mail will not go to > an unwitting victim of a spoofed address. > > Am I missing something? Two things: 1) Of course, 2821.MAIL FROM is not 2822.FROM, 2) BOUNCE is for non-deliverables, not "non authenticated messages." We should be careful to mix bounce semantics. We have the possible technical logic: A - Message Deliverable Status (1, 0) B - Message Authentication Status (1, 0, ?) That gives you 6 possible scenarios: A1, B1 --> PERFECT WORLD! A1, B0 --> DROP, BOUNCE DOES NOT APPLY A1, B? --> DROP MAYBE?, BOUNCE DOES NOT APPLY A0, B1 --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE A0, B0 --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE A0, B? --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE Maybe you thinking DKIM STATUS REPORTING feedback concept? In my book, RFC2822 is a 2nd stage consideration. 2821 comes first and for systems doing 2821 level successful checks, the BOUNCE is considered "USEABLE." In other words, in order to avoid bounce attacks, the 2821 system has to do its checks outside of 2822 considerations such as DKIM. This might include SSP checking before the message is ACCEPTED at the DATA level, and the only type of SSP you should check for is for your basic SSP/DKIM violations as described in DSAP. - NO-MAIL EXPECTATION - NO SIGNATURE EXPECTED/BUT MSG IS SIGNED - SIGNATURE EXPECTED/BUT MSG IS NOT SIGNED DKIM validation is not required. This is what we are doing in our products, and in fact, are currently adding the logic to our List Server where it does some rudimentary subscription DKIM POLICY checks. -- Sincerely 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 From ietf-dkim-bounces@mipassoc.org Sat Jul 07 13:34:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7EBI-0006TT-Al for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 13:34:53 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7EBD-0002GW-Tv for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 13:34:52 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67HXl4O019415; Sat, 7 Jul 2007 10:33:47 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67HXck1019360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 7 Jul 2007 10:33:38 -0700 Received: from [192.168.0.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l67HXaU9026454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jul 2007 10:33:44 -0700 Message-ID: <468FCF5A.5030101@mtcc.com> Date: Sat, 07 Jul 2007 10:37:30 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> <468EF2D9.9040406@dcrocker.net> <914A44BE-D737-48A9-821F-D36FA9B114D5@blighty.com> <468FB483.5060609@dcrocker.net> In-Reply-To: <468FB483.5060609@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Dave Crocker wrote: > > > Steve Atkins wrote: >>> Given the DKIM sig and the "Return" SSP record, I'll generate it >>> since the return address domain has said it's valid. >> >> Wouldn't you be better looking at the i= tag in the DKIM-Signature >> header, anyway? > > > Since it's optional, I hadn't thought to rely on it. > > Since it's intent is different, I'd be concerned about *requiring* i= > as the sole means for resolving this. > > That said, if the i= is present AND it matches the rfc2821.MailFrom, > then it does indeed seem like it closes the hole that you observed. > > So the Bounce SSP record would only be needed if the domains matched > and there were no i=. > > The implied question that John L. raises -- squelch at source vs. > squelch at destination -- is entirely valid. I think it boils down > to: Is it worth the administrative, operational and computational > overhead of this extra mechanism to prevent generation of specious > bounces? An interesting side effect is that it would also suppress bounce messages from mailing lists, even if they resigned. I'm not sure if this is a feature or a bug. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 13:58:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7EXj-00083i-1m for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 13:58:03 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7EXe-000352-LQ for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 13:58:03 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67HvKX4024106; Sat, 7 Jul 2007 10:57:25 -0700 Received: from [192.168.0.3] (ppp-68-120-198-72.dsl.pltn13.pacbell.net [68.120.198.72]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67HvFC1024084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Jul 2007 10:57:15 -0700 Message-ID: <468FD3AD.6060508@dcrocker.net> Date: Sat, 07 Jul 2007 10:55:57 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> <468EF2D9.9040406@dcrocker.net> <914A44BE-D737-48A9-821F-D36FA9B114D5@blighty.com> <468FB483.5060609@dcrocker.net> <468FCF5A.5030101@mtcc.com> In-Reply-To: <468FCF5A.5030101@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Michael Thomas wrote: > An interesting side effect is that it would also suppress bounce messages > from mailing lists, even if they resigned. I'm not sure if this is a > feature or a bug. I think that that will depend entirely on the way the SSP record is defined, much like the constraints on rfc2821.From values that are being discussed. So, yeah, if the SSP associated with the MailFrom says "rfc2821.MailFrom" must match a DKIM signature, or somesuch, then a mailing list that inserts its own MailFrom, without adding its own signature, could break bounces. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 17:07:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7HVW-0002xO-IR for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 17:07:58 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7HVS-0007ai-5Y for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 17:07:58 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67L5rZI029771; Sat, 7 Jul 2007 14:06:07 -0700 Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67L5kbH029688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Jul 2007 14:05:47 -0700 Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 814CF5CC153 for ; Sat, 7 Jul 2007 21:05:50 +0000 (UTC) Received: from [192.168.111.102] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) by mailout00.controlledmail.com (Postfix) with ESMTP id 70B665CC12C for ; Sat, 7 Jul 2007 21:05:50 +0000 (UTC) From: Scott Kitterman To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Sat, 7 Jul 2007 17:05:48 -0400 User-Agent: KMail/1.9.5 References: <468ED9B3.8070602@dcrocker.net> In-Reply-To: <468ED9B3.8070602@dcrocker.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200707071705.48160.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Friday 06 July 2007 20:09, Dave Crocker wrote: > Folks, > > I'm not sure whether this fits into SSP or not, since it does not seem to > require that a record be published. However... > > It seems to me that if a message has a DKIM signature and the signing > domain matches the domain in the rfc2821.MailFrom command, then it is safe > to generate a bounce message to that address. > > By 'safe' I mean that one can be confident that the mail will not go to an > unwitting victim of a spoofed address. victim/domain yes. > Am I missing something? > > d/ I'm sure the protocol police would be out in force as this is a layer violation, but I expect if limited to the case where 2821 Mail From domain is the same as the signing domain it would likely be reasonably effective. SPF Pass would (if available) give you the same or better confidence. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 07 17:10:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7HXx-00051g-W4 for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 17:10:29 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7HXt-0007on-Iq for ietf-dkim-archive@lists.ietf.org; Sat, 07 Jul 2007 17:10:29 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67L9mMZ030616; Sat, 7 Jul 2007 14:09:48 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l67L9cLd030545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 7 Jul 2007 14:09:38 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 56D124142A; Sat, 7 Jul 2007 14:09:46 -0700 (PDT) In-Reply-To: <468FD3AD.6060508@dcrocker.net> References: <468ED9B3.8070602@dcrocker.net> <468EDEAA.5080501@dcrocker.net> <1B5A8E59-0ED1-4960-BB08-65CD35214A77@blighty.com> <468EF2D9.9040406@dcrocker.net> <914A44BE-D737-48A9-821F-D36FA9B114D5@blighty.com> <468FB483.5060609@dcrocker.net> <468FCF5A.5030101@mtcc.com> <468FD3AD.6060508@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2A0E8DCA-E5A8-4F32-BED6-4E4C337B8122@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? Date: Sat, 7 Jul 2007 14:10:18 -0700 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb On Jul 7, 2007, at 10:55 AM, Dave Crocker wrote: > > > Michael Thomas wrote: >> An interesting side effect is that it would also suppress bounce >> messages from mailing lists, even if they resigned. I'm not sure >> if this is a feature or a bug. > > I think that that will depend entirely on the way the SSP record is > defined, much like the constraints on rfc2821.From values that are > being discussed. > > So, yeah, if the SSP associated with the MailFrom says > "rfc2821.MailFrom" must match a DKIM signature, or somesuch, then a > mailing list that inserts its own MailFrom, without adding its own > signature, could break bounces. What is lacking is a defined strategy to deal with possible replay abuse. It could be assumed a signing domain has some strategy to handle replay abuse originating within their own domain. This replay abuse can result from MailFrom bounces, or from forwarded messages. Traffic from mailing lists will require exceptional handling, especially when the message signature has not been invalidated. BATV will not help when a message passes through a mailing list. BATV must also restrict where messages are allowed to originate to those outbound servers sharing the encoding secret. Avoiding the initiation of a bounce independent of whether some email- address matches that of the MailFrom, would be to note whether the SMTP client was within the signing domain. When the SMTP client is within the signing domain, the chance of a message being a replay diminishes greatly. This would not require any email-address contained within the message to match that of the signing domain. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 12:33:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7Zh8-0002kF-M0 for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 12:33:10 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7Zh4-0008TV-9h for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 12:33:10 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68GVATC005720; Sun, 8 Jul 2007 09:31:15 -0700 Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68GURvF005569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 Jul 2007 09:30:28 -0700 Received: (qmail 99681 invoked from network); 8 Jul 2007 16:30:35 -0000 Received: from mail1.iecc.com (208.31.42.56) by mail1.iecc.com with QMQP; 8 Jul 2007 16:30:35 -0000 Date: 8 Jul 2007 16:30:35 -0000 Message-ID: <20070708163035.9409.qmail@simone.iecc.com> From: John Levine To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? In-Reply-To: <468FD3AD.6060508@dcrocker.net> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Songbird: Clean, Clean Cc: dcrocker@bbiw.net X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: -0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 >> An interesting side effect is that it would also suppress bounce messages >> from mailing lists, even if they resigned. I'm not sure if this is a >> feature or a bug. >So, yeah, if the SSP associated with the MailFrom says >"rfc2821.MailFrom" must match a DKIM signature, or somesuch, then a >mailing list that inserts its own MailFrom, without adding its own >signature, could break bounces. I wouldn't worry too much about that scenario, since if anyone sets that flag, everyone will be throwing away his mailing list mail anyway. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 14:20:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7bMh-00067v-RR for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 14:20:11 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7bMd-0002oq-Et for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 14:20:11 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68IIaSh026694; Sun, 8 Jul 2007 11:18:46 -0700 Received: from [192.168.0.3] (ppp-67-124-90-112.dsl.pltn13.pacbell.net [67.124.90.112]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68IIRFv026661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 11:18:27 -0700 Message-ID: <46912A23.5050105@dcrocker.net> Date: Sun, 08 Jul 2007 11:17:07 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: John Levine Subject: Re: [ietf-dkim] DKIM signature can mean it's safe to generate bounce? References: <20070708163035.9409.qmail@simone.iecc.com> In-Reply-To: <20070708163035.9409.qmail@simone.iecc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 John Levine wrote: >>> An interesting side effect is that it would also suppress bounce messages >>> from mailing lists, even if they resigned. I'm not sure if this is a >>> feature or a bug. > >> So, yeah, if the SSP associated with the MailFrom says >> "rfc2821.MailFrom" must match a DKIM signature, or somesuch, then a >> mailing list that inserts its own MailFrom, without adding its own >> signature, could break bounces. > > I wouldn't worry too much about that scenario, since if anyone sets that > flag, everyone will be throwing away his mailing list mail anyway. I think this depends upon the definition of 'this flag' and what range of assertions is permits. If it is a one-bit flag, then you are no-doubt correct. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 14:45:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7bkj-0002NH-FU for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 14:45:01 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7bkf-0003Gz-1c for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 14:45:01 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68IhlZ4031825; Sun, 8 Jul 2007 11:43:48 -0700 Received: from [192.168.0.3] (ppp-67-124-90-112.dsl.pltn13.pacbell.net [67.124.90.112]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68IheQr031798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2007 11:43:41 -0700 Message-ID: <4691300D.5000001@dcrocker.net> Date: Sun, 08 Jul 2007 11:42:21 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Subject: [ietf-dkim] Choices about Practice vs. Publication X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 An offline discussion with Steve Atkins has been helpful in highlighting a two distinctions in function and implementation design that the group should consider. He pressed quite hard, for some of what follows, but I won't claim that I'm speaking on his behalf; I just want to make sure it's clear that I didn't "invent" any of this: 1. Internal vs. External The difference between recruiting the recipient to enforce origin-side policies concerning origin-side participants, versus enabling the recipient to detect misbehaviors by actors external to the origin-side. I think a simple and appropriate model, here, is that the receive-side should be given information that permits it to detect external attacks -- that is, misbehaviors by actors external to the origin-side. The receive-side should *not* be recruited to enforce policies pertaining to participants within the origin-side environment. The latter is strictly the job of the origin-side organization. 2. Practice vs. Publication Classically, this is the "what vs. how" distinction. What is the information that the 'sender' or signer wants to communicate to the receiver? Distinct from this is the means by which it is communicated. The two obvious choices for communicating anything involving DKIM are: a) DNS publication, versus b) inclusion in the signed message, either as an enhancement to an existing header field, or as a new field. Of course each of these has notable benefits and limitations DNS queries have particular performance characteristics, concerning cost, reliability and latency. Its major benefit is that it is an out-of-band channel. Where that is essential -- such as communicating information that can be applied to unsigned messages -- then it is what should be used. However if the information is from a signer -- and it does not somehow require independent trust, such as obtaining it from a third-party service -- then it can be included in the message. Steve pointed out to me that a basic challenge, here, is that DKIM does not define a signature as meaning that the signer is asserting the truthfulness of any particular bit of information in the message. That's the inherent difference between the mild "taking responsibility" semantics that we have given to a DKIM signature, versus "asserting correctness" or the like. My suggestion to deal with this is to define the basic DKIM sematnic that all DKIM-* headers are asserted to be valid, if they are included in the signature. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 15:17:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7cGc-0004gb-U0 for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 15:17:58 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7cGY-0003yc-F3 for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 15:17:58 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68JGv0V006248; Sun, 8 Jul 2007 12:16:58 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68JGnAZ006213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 Jul 2007 12:16:50 -0700 Received: from [192.168.0.101] (sj-natpool-220.cisco.com [128.107.248.220]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l68JGtMD007622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 12:16:57 -0700 Message-ID: <46913920.5020200@mtcc.com> Date: Sun, 08 Jul 2007 12:21:04 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] Choices about Practice vs. Publication References: <4691300D.5000001@dcrocker.net> In-Reply-To: <4691300D.5000001@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Dave Crocker wrote: > 1. Internal vs. External > > The difference between recruiting the recipient to enforce > origin-side policies concerning origin-side participants, versus > enabling the recipient to detect misbehaviors by actors external to > the origin-side. > > I think a simple and appropriate model, here, is that the > receive-side should be given information that permits it to detect > external attacks -- that is, misbehaviors by actors external to the > origin-side. > > The receive-side should *not* be recruited to enforce policies > pertaining to participants within the origin-side environment. The > latter is strictly the job of the origin-side organization. In which case, the bob and jane @ earthlink problem is really earthlink's to deal with. I think that's entirely appropriate; it is completely within earthlink's capability to, say, use SMTP AUTH to gate users to deal with this attack. > > > > 2. Practice vs. Publication > > Classically, this is the "what vs. how" distinction. > > What is the information that the 'sender' or signer wants to > communicate to the receiver? Distinct from this is the means by which > it is communicated. > > The two obvious choices for communicating anything involving DKIM are: > > a) DNS publication, versus > > b) inclusion in the signed message, either as an enhancement > to an existing header field, or as a new field. There's really a third dimension too: the "unsigned" message problem. > > Of course each of these has notable benefits and limitations > > DNS queries have particular performance characteristics, concerning > cost, reliability and latency. Its major benefit is that it is an > out-of-band channel. Where that is essential -- such as communicating > information that can be applied to unsigned messages -- then it is > what should be used. > > However if the information is from a signer -- and it does not > somehow require independent trust, such as obtaining it from a > third-party service -- then it can be included in the message. > The subdivision of labor with DKIM has pretty much been: if it's something that constrains a key, then it goes in the DNS record. Everything else goes in the signature header. This seems pretty clean. > > Steve pointed out to me that a basic challenge, here, is that DKIM > does not define a signature as meaning that the signer is asserting > the truthfulness of any particular bit of information in the message. > That's the inherent difference between the mild "taking > responsibility" semantics that we have given to a DKIM signature, > versus "asserting correctness" or the like. > > My suggestion to deal with this is to define the basic DKIM > sematnic that all DKIM-* headers are asserted to be valid, if they are > included in the signature. I'm not really sure where you're going with this, and I don't think I like the implications. If a signer asserts something, it's motivation for asserting it has to always be viewed with the possibility of being gamed. So I don't know what "valid" means through that lens. Useful information to a receiver can only be of the "negative" variety; economists probably have language for this, but information that there is no incentive for the signer to lie about. Typically these are things that constrain the degrees of freedom rather than increase them, which is exactly what the current crop of tags in DKIM do. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 16:31:34 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7dPq-0000Zc-FP for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 16:31:34 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7dPm-00067t-0d for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 16:31:34 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68KUC2R011212; Sun, 8 Jul 2007 13:30:17 -0700 Received: from [192.168.0.3] (ppp-67-124-90-112.dsl.pltn13.pacbell.net [67.124.90.112]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68KTlA6010989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2007 13:29:48 -0700 Message-ID: <469148EC.3040504@dcrocker.net> Date: Sun, 08 Jul 2007 13:28:28 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: DKIM IETF WG Content-Type: multipart/mixed; boundary="------------040607060309030906020204" X-Songbird: Clean, Clean Subject: [ietf-dkim] [Fwd: I-D ACTION:draft-wallace-ta-mgmt-problem-statement-01.txt] X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 This is a multi-part message in MIME format. --------------040607060309030906020204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Of possible interest to the DKIM community: -------- Original Message -------- Subject: I-D ACTION:draft-wallace-ta-mgmt-problem-statement-01.txt Date: Sun, 08 Jul 2007 16:15:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Trust Anchor Management Problem Statement Author(s) : R. Reddy, C. Wallace Filename : draft-wallace-ta-mgmt-problem-statement-01.txt Pages : 14 Date : 2007-7-8 This document provides a problem statement for the Trust Anchor Management Birds of a Feather (BOF). Trust anchors are public keys and associated information that are directly trusted by an application or system to validate digital signatures, including signatures covering other public keys. At present, there exists no standard mechanism for distributing and managing trust anchors. This document describes some of the problems associated with the lack of a standard trust anchor management mechanism as well as problems that must be addressed by such a mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-wallace-ta-mgmt-problem-statement-01.txt -- Dave Crocker Brandenburg InternetWorking bbiw.net --------------040607060309030906020204 Content-Type: Message/External-body; name="draft-wallace-ta-mgmt-problem-statement-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-wallace-ta-mgmt-problem-statement-01.txt" Content-Type: text/plain Content-ID: <2007-7-8151537.I-D@ietf.org> --------------040607060309030906020204 Content-Type: text/plain; name="file:///C:/DOCUME~1/DCROCK~1.BBD/LOCALS~1/TEMP/nsmail.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="file:///C:/DOCUME~1/DCROCK~1.BBD/LOCALS~1/TEMP/nsmail.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------040607060309030906020204 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html --------------040607060309030906020204-- From ietf-dkim-bounces@mipassoc.org Sun Jul 08 17:13:22 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7e4I-0005i4-Oy for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 17:13:22 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7e4E-0007Fe-CL for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 17:13:22 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68LBFqt002847; Sun, 8 Jul 2007 14:11:15 -0700 Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68L9WVh002026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2007 14:09:32 -0700 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l68L9ZRL003404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 14:09:38 -0700 (MST) (envelope-from paul.hoffman@domain-assurance.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <469148EC.3040504@dcrocker.net> References: <469148EC.3040504@dcrocker.net> Date: Sun, 8 Jul 2007 14:08:59 -0700 To: dcrocker@bbiw.net, DKIM IETF WG From: Paul Hoffman Subject: Re: [ietf-dkim] [Fwd: I-D ACTION:draft-wallace-ta-mgmt-problem-statement-01.txt] Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Songbird: Clean, Clean Cc: X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 So, as someone very interested in the trust anchor work, I don't want to discourage anyone here from following it, but I think it is completely unrelated to DKIM. DKIM, of course, doesn't need trust anchors, and the TAM work is all about trust anchors. (Well, there is some crossover because one of the DKIM co-chairs is co-chairing the TAM BoF in Chicago, but that's about it.) --Paul Hoffman, Director --Domain Assurance Council _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 17:15:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7e65-0007t7-2V for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 17:15:13 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7e61-0007HU-Mi for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 17:15:13 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68LCDdQ003309; Sun, 8 Jul 2007 14:12:14 -0700 Received: from relay.imagine.ie (dns1.dns.imagine.ie [87.232.1.40]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68LAkuL002530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 8 Jul 2007 14:10:47 -0700 Received: from mail1.int.imagine.ie (mail1 [87.232.1.152]) by relay.imagine.ie (Postfix) with ESMTP id AB2E53216E; Sun, 8 Jul 2007 22:10:51 +0100 (IST) Received: from [10.87.48.2] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by mail1.int.imagine.ie (8.13.4/8.13.4/Debian-3) with ESMTP id l68LAna5019501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Jul 2007 22:10:50 +0100 Message-ID: <46915349.6060208@cs.tcd.ie> Date: Sun, 08 Jul 2007 22:12:41 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] [Fwd: I-D ACTION:draft-wallace-ta-mgmt-problem-statement-01.txt] References: <469148EC.3040504@dcrocker.net> In-Reply-To: <469148EC.3040504@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Bayes-Prob: 0.0201 (Score 0) X-Spam-Score: 0.00 () [Hold at 8.00] X-Canit-Stats-ID: 11330370 - 4336587747e8 (trained as not-spam) X-CanItPRO-Stream: outgoing X-Scanned-By: CanIt (www . roaringpenguin . com) on 87.232.1.52 X-Songbird: Clean, Clean Cc: DKIM IETF WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Dave Crocker wrote: > > Of possible interest to the DKIM community: To the community, quite possibly. But I don't see much to do with the DKIM protocol, as currently spec'd. If, however, someone started using X.509 certs, XKMS or DNSSEC to support DKIM, then yes, it'd start to be relevant. Or am I missing something? S. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 18:06:47 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7ety-0002OX-VK for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 18:06:46 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7etu-0001Pk-IY for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 18:06:46 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68M3Wj0002657; Sun, 8 Jul 2007 15:03:37 -0700 Received: from [192.168.0.3] (ppp-67-124-90-112.dsl.pltn13.pacbell.net [67.124.90.112]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68M1Nex001440 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Jul 2007 15:01:24 -0700 Message-ID: <46915E64.1040909@dcrocker.net> Date: Sun, 08 Jul 2007 15:00:04 -0700 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Stephen Farrell Subject: Re: [ietf-dkim] [Fwd: I-D ACTION:draft-wallace-ta-mgmt-problem-statement-01.txt] References: <469148EC.3040504@dcrocker.net> <46915349.6060208@cs.tcd.ie> In-Reply-To: <46915349.6060208@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: DKIM IETF WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Stephen Farrell wrote: > Dave Crocker wrote: >> Of possible interest to the DKIM community: > > To the community, quite possibly. But I don't see much > to do with the DKIM protocol, as currently spec'd. If, > however, someone started using X.509 certs, XKMS or > DNSSEC to support DKIM, then yes, it'd start to be > relevant. Or am I missing something? Well, between your note and Paul's I'm now sorry I passed the anchor announcement on, even though I did only say "of possible interest". It is interesting, nonetheless, that the latter part of your message provides some perfectly reasonable examples of why the anchor work might be "of interest" to DKIM folk... Other possibilities might have to do with what domain names might sign what messages or even what DKIM signatures might sign existing DKIM signatures, or... "of possible interest" wasn't meant to be specific but merely to suggest and area of consideration. For individuals, not the working group. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 19:43:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7gQ2-0002Yz-Uo for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 19:43:58 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7gPy-0004mr-BS for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 19:43:58 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68NdR1V025144; Sun, 8 Jul 2007 16:39:35 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68NaU8R022870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2007 16:36:30 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 3130E4143C; Sun, 8 Jul 2007 16:36:34 -0700 (PDT) In-Reply-To: <4691300D.5000001@dcrocker.net> References: <4691300D.5000001@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Choices about Practice vs. Publication Date: Sun, 8 Jul 2007 16:37:05 -0700 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f On Jul 8, 2007, at 11:42 AM, Dave Crocker wrote: > An offline discussion with Steve Atkins has been helpful in > highlighting a two distinctions in function and implementation > design that the group should consider. He pressed quite hard, for > some of what follows, but I won't claim that I'm speaking on his > behalf; I just want to make sure it's clear that I didn't "invent" > any of this: > > 1. Internal vs. External > > The difference between recruiting the recipient to enforce > origin-side policies concerning origin-side participants, versus > enabling the recipient to detect misbehaviors by actors external to > the origin-side. > > I think a simple and appropriate model, here, is that the > receive-side should be given information that permits it to detect > external attacks -- that is, misbehaviors by actors external to the > origin-side. > > The receive-side should *not* be recruited to enforce policies > pertaining to participants within the origin-side environment. The > latter is strictly the job of the origin-side organization. There will not be much sympathy for having bounced replay abuse, when the victim is also the signing domain. Be aware that IP reputation schemes may not be generous to those bouncing the message. In addition, there are many domains where "same-domain" replay abuse might become problematic. Those forwarding messages into such a domain will appear fairly similar to "same-domain" replay abuse. It should not be assumed "same-domain" replay abuse only occurs via a spoofed MailFrom addresses where BATV might prove useful. > 2. Practice vs. Publication > > Classically, this is the "what vs. how" distinction. > > What is the information that the 'sender' or signer wants to > communicate to the receiver? Distinct from this is the means by > which it is communicated. > > The two obvious choices for communicating anything involving > DKIM are: > > a) DNS publication, versus DKIM is normally related to the "originating" domain, but DKIM can also be added by subsequent domains. When attempting to ascertain a potential for replay abuse, finding the SMTP client within the signing domain precludes a replay abuse concern. When an originating email-address domain differs from that of a subsequent signing domain, then ONLY WHEN the signing domain has been explicitly authorized by the originating domain can replay abuse be excluded. Without an ability to preclude possible replay abuse, acceptance will likely remain based upon the reputation of the SMTP client's IP address. Transparent authorization accomplished through an exchange of keys defeats being able to preclude the potential for replay abuse. Even when the originator and the subsequent provider both sign, explicit authorization is needed to permit the SMTP client to be within the signing domain of the originating email-address. An explicit authorization via a DNS record can provide such authorization by- name. The method can be very scalable and within a single transaction which is likely needed anyway. Relying upon SPF/Sender-ID as a type of authorization places DNS itself at risk where this scheme might incur many additional transactions. In addition, SPF/Sender-ID is based upon constructing comprehensive IP address lists. As IPv6 use increases, IP addresses will become fairly dynamic as well. When the message is unsigned, the check will be for a normal SSP RR. When the message is signed, a check could be for a TPA-SSP RR instead. Even a subsequent transaction for the SSP RR could be eliminated by a wildcard below the SSP record. Even so, wildcard records should be avoided. The next transaction will likely check the existence of an MX or A RRs to validate the email-address domain. This approach precludes transactions traversing the entire domain. > b) inclusion in the signed message, either as an > enhancement to an existing header field, or as a new field. A signing domain may wish to make assurances related to the validity of the MailFrom address. Such an assurance may improve the integrity of DSNs when the MailFrom email-address differs from that of the 'i=' parameter. Such a header could also assure "authorized" domains which might differ entirely from that of the signing domain. Such a feature could also assist with "same-domain" replay abuse resulting from spoofed bounce addresses. In this case, the header would not need to be standardized. > Of course each of these has notable benefits and limitations > > DNS queries have particular performance characteristics, > concerning cost, reliability and latency. Its major benefit is that > it is an out-of-band channel. Where that is essential -- such as > communicating information that can be applied to unsigned messages > -- then it is what should be used. > > However if the information is from a signer -- and it does not > somehow require independent trust, such as obtaining it from a > third-party service -- then it can be included in the message. This would be true except when dealing with possible replay abuse. When the ability to replay DKIM messages is exploited, deliverability of a message may depend upon being able to determine a relationship between the SMTP client and that of the signing domain. Otherwise, the IP address used by the client remains the only safe reference to base reputations. > Steve pointed out to me that a basic challenge, here, is that > DKIM does not define a signature as meaning that the signer is > asserting the truthfulness of any particular bit of information in > the message. That's the inherent difference between the mild > "taking responsibility" semantics that we have given to a DKIM > signature, versus "asserting correctness" or the like. > > My suggestion to deal with this is to define the basic DKIM > sematnic that all DKIM-* headers are asserted to be valid, if they > are included in the signature. This assertion in many cases would need to exclude the From address, but this header is required to be signed. Use of the "i=' parameter is likely the only positive means to communicate such an assurance and is already defined within DKIM base. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 19:52:18 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7gY6-0005pa-1D for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 19:52:18 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7gY1-0004yw-6h for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 19:52:18 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68Nn7kV031982; Sun, 8 Jul 2007 16:49:08 -0700 Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l68NkV14030234 for ; Sun, 8 Jul 2007 16:46:31 -0700 Received: from [10.3.2.25] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 388F08010C for ; Sun, 8 Jul 2007 16:46:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <4691300D.5000001@dcrocker.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D37F7FB-7192-4CA3-B60C-C50CF425A78B@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [ietf-dkim] Choices about Practice vs. Publication Date: Sun, 8 Jul 2007 16:46:38 -0700 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 On Jul 8, 2007, at 4:37 PM, Douglas Otis wrote: > >> Steve pointed out to me that a basic challenge, here, is that >> DKIM does not define a signature as meaning that the signer is >> asserting the truthfulness of any particular bit of information in >> the message. That's the inherent difference between the mild >> "taking responsibility" semantics that we have given to a DKIM >> signature, versus "asserting correctness" or the like. >> >> My suggestion to deal with this is to define the basic DKIM >> sematnic that all DKIM-* headers are asserted to be valid, if they >> are included in the signature. > > This assertion in many cases would need to exclude the From > address, but this header is required to be signed. Use of the "i=' > parameter is likely the only positive means to communicate such an > assurance and is already defined within DKIM base. "From" does not start with "DKIM-". Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 08 23:24:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7jrQ-0000up-Mg for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 23:24:28 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7jrM-0000vv-9U for ietf-dkim-archive@lists.ietf.org; Sun, 08 Jul 2007 23:24:28 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l693IN4K018024; Sun, 8 Jul 2007 20:18:31 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l693Ebak014741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 8 Jul 2007 20:14:37 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 8CC054142A; Sun, 8 Jul 2007 20:14:45 -0700 (PDT) In-Reply-To: <9D37F7FB-7192-4CA3-B60C-C50CF425A78B@blighty.com> References: <4691300D.5000001@dcrocker.net> <9D37F7FB-7192-4CA3-B60C-C50CF425A78B@blighty.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <522561E9-A62B-4F3B-8BA1-AB696F03A6D0@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Choices about Practice vs. Publication Date: Sun, 8 Jul 2007 20:15:16 -0700 To: Steve Atkins X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 On Jul 8, 2007, at 4:46 PM, Steve Atkins wrote: > > On Jul 8, 2007, at 4:37 PM, Douglas Otis wrote: > >> >>> Steve pointed out to me that a basic challenge, here, is that >>> DKIM does not define a signature as meaning that the signer is >>> asserting the truthfulness of any particular bit of information >>> in the message. That's the inherent difference between the mild >>> "taking responsibility" semantics that we have given to a DKIM >>> signature, versus "asserting correctness" or the like. >>> >>> My suggestion to deal with this is to define the basic DKIM >>> sematnic that all DKIM-* headers are asserted to be valid, if >>> they are included in the signature. >> >> This assertion in many cases would need to exclude the From >> address, but this header is required to be signed. Use of the >> "i=' parameter is likely the only positive means to communicate >> such an assurance and is already defined within DKIM base. > > "From" does not start with "DKIM-". The From: field is intimately combined with the DKIM-Signature: field. Per rfc4871: --- 5.4. Determine the Header Fields to Sign The From header field MUST be signed (that is, included in the "h=" tag of the resulting DKIM-Signature header field). ___ Are you suggesting the intent is to sign other DKIM-Signatures and thereby assert they are also valid? -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Tue Jul 10 17:17:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8N5P-0003t2-IN for ietf-dkim-archive@lists.ietf.org; Tue, 10 Jul 2007 17:17:31 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8N5J-0003vD-0D for ietf-dkim-archive@lists.ietf.org; Tue, 10 Jul 2007 17:17:31 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6ALFXHi003441; Tue, 10 Jul 2007 14:15:34 -0700 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6ALFMiC003374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 10 Jul 2007 14:15:22 -0700 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l6ALFStT006699; Tue, 10 Jul 2007 14:15:29 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jul 2007 14:15:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Date: Tue, 10 Jul 2007 14:15:28 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37565E41@MOU1WNEXMB04.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Thread-Index: Ace/8v0SjG2FfVj2RMaL0Xgj7zk9gwDQh6g2 References: <4679619A.9060400@cs.tcd.ie> <468D61D3.7020905@cisco.com> From: "Hallam-Baker, Phillip" To: "Douglas Otis" , "Jim Fenton" X-OriginalArrivalTime: 10 Jul 2007 21:15:29.0119 (UTC) FILETIME=[711556F0:01C7C337] X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1670621704==" Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba This is a multi-part message in MIME format. --===============1670621704== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C337.70DC2108" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C337.70DC2108 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: ietf-dkim-bounces@mipassoc.org on behalf of Douglas Otis On Jul 5, 2007, at 2:25 PM, Jim Fenton wrote: =09 > I have seen a few comments on the list, in particular Phillip's=20 > comment about the downgrade attack that we need to discuss more. =20 > If any of you are holding onto comments, please go ahead. =09 While Phillip is correct about the downgrade issue, the key record=20 would need to be modified instead of an SSP record. The SSP record=20 is only checked when the message is not signed by a domain that is at=20 or above the email address domain. =09 I would like to discuss the downgrade attack certainly. We have to = address the attack either by solving it or by explaining it in the = security considerations. Doug's statement above is not correct though. A recipient ONLY looks at = the policy record if it does not find an acceptable signature record. = That means: A) The message has no signature at all B) The message has a signature header but it fails to verify C) The message has a signature that references a signature key for an = algorithm that is not acceptably secure D) The message has a signature that references a signature key for an = algorithm that the recipient is unable to verify. The outcome from signature verification is binary: either a valid = signature was found, or it was not. A client that implements BASE alone = is not allowed to distinguish between the four cases above. This limits = the field of application to whitelisting good mail. With policy we have three outcomes, the outcome 'not found' is expanded = to 'compliant with policy' or 'not compliant with policy'. The point about the upgrade/downgrade attack is that a DKIM policy is = determined by both the key records and the policy records. A key record = is an implicit statement that the signer MAY use the specified key to = sign a message.=20 We want to be able to ensure that a recipient is able to correctly = determine whether a message signature is or is not compliant with policy = in cases C and D. Without the ability to code the policy 'every message = is signed with an RSA key and a EC-DSA key' we are unable to publish an = EC-DSA key without allowing the attacker to negate our policy. The information about the algorithms is kept in the key records, what we = need in the policy section is a restriction on the key selectors. =20 What I propose here is to eliminate the 'partial signature' policy = statements that Jim has defined and replace them with the ability to = specify restrictions on the signing keys. This is neutral from a = complexity point of view. We eliminate a useless option and replace it = with an option we very much need. ------_=_NextPart_001_01C7C337.70DC2108 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [ietf-dkim] I-D = Action:draft-ietf-dkim-ssp-00.txt=0A= =0A= =0A= =0A=
=0A=
From: = ietf-dkim-bounces@mipassoc.org on behalf of Douglas = Otis
=0A=
=0A=
=0A=

On Jul 5, 2007, at 2:25 PM, Jim Fenton = wrote:

> I have seen a few comments on the list, in particular = Phillip's 
> comment about the downgrade attack that we need = to discuss more.  
> If any of you are holding onto = comments, please go ahead.

While Phillip is correct about the = downgrade issue, the key record 
would need to be modified = instead of an SSP record.  The SSP record 
is only checked = when the message is not signed by a domain that is at 
or above = the email address domain.

=0A=

I would like to discuss the downgrade attack = certainly. We have to address the attack either by = solving it or by explaining it in the security considerations.

=0A=

Doug's statement above is not correct = though. A recipient ONLY looks at the policy record if it does not find = an acceptable signature record. That means:

=0A=

A) The message has no signature at = all

=0A=

B) The message has a signature header but it = fails to verify

=0A=

C) The message has a signature that = references a signature key for an algorithm that is not acceptably = secure

=0A=

D) The message has a signature that = references a signature key for an algorithm that = the recipient is unable to verify.

=0A=

The outcome from signature verification is = binary: either a valid signature was found, or it was not. A client that = implements BASE alone is not allowed to distinguish between the four = cases above. This limits the field of application to whitelisting good = mail.

=0A=

With policy we have three outcomes, the = outcome 'not found' is expanded to 'compliant with policy' or 'not = compliant with policy'.

=0A=

The point about the upgrade/downgrade attack = is that a DKIM policy is determined by both the key records and the = policy records. A key record is an implicit statement that the signer = MAY use the specified key to sign a message.

=0A=

We want to be able to ensure that a = recipient is able to correctly determine whether a message signature is = or is not compliant with policy in cases C and D. Without the ability to = code the policy 'every message is signed with an RSA key and = a EC-DSA key' we are unable to publish an EC-DSA key without = allowing the attacker to negate our policy.

=0A=

The information about the algorithms is kept = in the key records, what we need in the policy section is a restriction = on the key selectors.

=0A=

 

=0A=

What I propose here is to eliminate the = 'partial signature' policy statements that Jim has defined and replace = them with the ability to specify restrictions on the signing keys. This = is neutral from a complexity point of view. We eliminate a useless = option and replace it with an option we very much = need.

------_=_NextPart_001_01C7C337.70DC2108-- --===============1670621704== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html --===============1670621704==-- From ietf-dkim-bounces@mipassoc.org Tue Jul 10 19:39:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8PIU-0000yd-Na for ietf-dkim-archive@lists.ietf.org; Tue, 10 Jul 2007 19:39:10 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8PIQ-0007c5-4s for ietf-dkim-archive@lists.ietf.org; Tue, 10 Jul 2007 19:39:10 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6ANbYpM032654; Tue, 10 Jul 2007 16:37:37 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6ANbHel032600 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2007 16:37:17 -0700 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id BB52641441; Tue, 10 Jul 2007 16:37:20 -0700 (PDT) In-Reply-To: <198A730C2044DE4A96749D13E167AD37565E41@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <4679619A.9060400@cs.tcd.ie> <468D61D3.7020905@cisco.com> <198A730C2044DE4A96749D13E167AD37565E41@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Date: Tue, 10 Jul 2007 16:37:57 -0700 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 On Jul 10, 2007, at 2:15 PM, Hallam-Baker, Phillip wrote: > I would like to discuss the downgrade attack certainly. We have to > address the attack either by solving it or by explaining it in the > security considerations. > > Doug's statement above is not correct though. A recipient ONLY > looks at the policy record if it does not find an acceptable > signature record. That means: > > A) The message has no signature at all > > B) The message has a signature header but it fails to verify > > C) The message has a signature that references a signature key for > an algorithm that is not acceptably secure > > D) The message has a signature that references a signature key for > an algorithm that the recipient is unable to verify. Don't forget. E) The message has a signature by a Third-Party domain. You are describing a policy conformance issue caused when an algorithm is upgraded, but not yet supported by the recipient. IMO, this is not a downgrade attack, although this could affect policy compliance. When the key is obtained, it should be possible to determine whether the key's algorithm is supported. Unfortunately, a key's notation will not cover all aspects of the signing and verification process. A downgrade attack might occur when two signatures are added to ensure compliance during an upgrade transition. There might be an attack made possible when a stronger algorithm is trivially defeated. This might happen when a weaker algorithm is accepted, although both algorithms are supported. Exploitation of a weaker algorithm could be considered a downgrade attack when a stronger algorithm is supported. The other situation might be removal of the weaker algorithm, where evidence a different algorithm is supported by the signing domain may offer some level of acceptance. Removal of the weaker algorithm and spoofing a stronger algorithm might be considers an a spoofed upgrade attack. Having a stronger signature algorithm signed by a weaker algorithm might be an expensive and perhaps fragile solution to a downgrade attack. However, this approach presupposes the nature of the weaker algorithm's exploit. Although a weaker algorithm may become problematic, abandoning a weaker algorithm may be untenable as this may invite conditions leading to a spoofed upgrade attack. Preventing a downgrade attack, without presupposing what the weakness might be, could be handled by defining a flag within the key indicating that it had been deprecated and what key pairs should be present. The purpose of the deprecated flag is to indicate that the key MUST BE accompanied by a stronger signature. Identifying the stronger and weaker algorithms should also be done within the keys to minimize overhead and preclude either a downgrade or spoofed upgrade attack. > The outcome from signature verification is binary: either a valid > signature was found, or it was not. A client that implements BASE > alone is not allowed to distinguish between the four cases above. > This limits the field of application to whitelisting good mail. Agreed. > With policy we have three outcomes, the outcome 'not found' is > expanded to 'compliant with policy' or 'not compliant with policy'. It would seem two signatures would be the only reasonable method for transitioning with a strict policy. As such, there should not be policy exceptions made based upon what only appears to be supported. The domain should be allowed to explicitly indicate what has been deprecated, and indicate what should be accompanied by each other signature within the keys. > The point about the upgrade/downgrade attack is that a DKIM policy > is determined by both the key records and the policy records. A key > record is an implicit statement that the signer MAY use the > specified key to sign a message. > > We want to be able to ensure that a recipient is able to correctly > determine whether a message signature is or is not compliant with > policy in cases C and D. Without the ability to code the policy > 'every message is signed with an RSA key and a EC-DSA key' we are > unable to publish an EC-DSA key without allowing the attacker to > negate our policy. It would seem any unsupported algorithm clearly falls into a 'not signed' category. When policy is strict, this would be within the 'not compliant with policy' category. > The information about the algorithms is kept in the key records, > what we need in the policy section is a restriction on the key > selectors. This is difficult to follow. How can a global policy differentiate whether it is okay to use selector A or B. One might presume both selectors are used or they would not be published. If one were to sign an email-address within a sub-domain, it could also utilize different keys within both higher and lower domains. The stronger signatures could be valid only for a sub-domain email-address whereas the weaker signature could be used for either domain without possible conflict. Authorization of signatures within sub-domains could be used. Restrictions of such authorizations could occur within a TPA-SSP without inducing additional overhead. : ) > What I propose here is to eliminate the 'partial signature' policy > statements that Jim has defined and replace them with the ability > to specify restrictions on the signing keys. This is neutral from a > complexity point of view. We eliminate a useless option and replace > it with an option we very much need. It is not clear what mechanism is being proposed. The TPA-SSP could be extended to include a '*+' local-part matching component as an added restriction. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Wed Jul 11 06:19:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ZII-0008AM-Eu for ietf-dkim-archive@lists.ietf.org; Wed, 11 Jul 2007 06:19:38 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ZID-0003Hf-Nu for ietf-dkim-archive@lists.ietf.org; Wed, 11 Jul 2007 06:19:38 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6BAI49h018245; Wed, 11 Jul 2007 03:18:11 -0700 Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6BAHpsE018203 for ; Wed, 11 Jul 2007 03:17:51 -0700 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster*pop3*clerew^man*ac&uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 4694ae56.d4ed.6c for ietf-dkim@mipassoc.org; Wed, 11 Jul 2007 11:17:58 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l6BAHtsk021912 for ; Wed, 11 Jul 2007 11:17:56 +0100 (BST) To: DKIM Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt References: <4679619A.9060400@cs.tcd.ie> <468D61D3.7020905@cisco.com> <198A730C2044DE4A96749D13E167AD37565E41@MOU1WNEXMB04.vcorp.ad.vrsn.com> Message-ID: Date: Wed, 11 Jul 2007 11:17:54 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id l6BAI49h018245 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca On Wed, 11 Jul 2007 00:37:57 +0100, Douglas Otis =20 wrote: > On Jul 10, 2007, at 2:15 PM, Hallam-Baker, Phillip wrote: > >> I would like to discuss the downgrade attack certainly. We have to =20 >> address the attack either by solving it or by explaining it in the =20 >> security considerations. >> >> Doug's statement above is not correct though. A recipient ONLY looks a= t =20 >> the policy record if it does not find an acceptable signature record. = =20 >> That means: Eh? A recipient can look at a policy record whenever he sees fit to do so= , =20 and for whatever reason. > E) The message has a signature by a Third-Party domain. And F) The signer seemed to be unrelated to the From/Sender/Whatever headers; G) The signature covered an "unusual" selection of headers; H) There were several signatures, of which some passed and some failed; I) Umpteen other reasons why it looked suspicious. A Policy Record might well clear up some (probably not all) of such cases= . =20 Moreover, experience will throw up new scams that the Bad Guys will =20 invent, and so it may become necessary to add new kinds of information to= =20 Policy records that we have not even thought of yet. So, to that extent, = =20 their notation needs to be extensible. --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0 =20 =A0=A0=A0Web:=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ NOTE WELL: This list operates according to=20 http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 12 10:38:14 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8zo5-0004sM-R9 for ietf-dkim-archive@lists.ietf.org; Thu, 12 Jul 2007 10:38:13 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8zo1-0004Ra-Bu for ietf-dkim-archive@lists.ietf.org; Thu, 12 Jul 2007 10:38:13 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6CEajWO000992; Thu, 12 Jul 2007 07:36:51 -0700 Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6CEaYhA000961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 12 Jul 2007 07:36:34 -0700 Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.13.6/8.13.4) with ESMTP id l6CEaGqu017734; Thu, 12 Jul 2007 07:36:20 -0700 Received: from MOU1WNEXMB04.vcorp.ad.vrsn.com ([10.25.13.157]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 07:36:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Date: Thu, 12 Jul 2007 07:34:34 -0700 Message-ID: <198A730C2044DE4A96749D13E167AD37012F6D64@MOU1WNEXMB04.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Thread-Index: AcfDpZbfill7WYg2SPWi+NYs9gFcYwA6vGsQ From: "Hallam-Baker, Phillip" To: "Charles Lindsey" , "DKIM" X-OriginalArrivalTime: 12 Jul 2007 14:36:19.0265 (UTC) FILETIME=[02AF2310:01C7C492] X-Songbird: Clean, Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sb7.songbird.com id l6CEaYhA000961 Cc: X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 > [mailto:ietf-dkim-bounces@mipassoc.org] On Behalf Of Charles Lindsey > Sent: Wednesday, July 11, 2007 6:18 AM > > On Jul 10, 2007, at 2:15 PM, Hallam-Baker, Phillip wrote: > > > >> I would like to discuss the downgrade attack certainly. We have to > >> address the attack either by solving it or by explaining it in the > >> security considerations. > >> > >> Doug's statement above is not correct though. A recipient > ONLY looks > >> at the policy record if it does not find an acceptable > signature record. > >> That means: > > Eh? A recipient can look at a policy record whenever he sees > fit to do so, and for whatever reason. This is true, in particular the verifier might well find it more efficient to pull a policy record before checking the signature. But an authenticated signature always dominates policy according to the specification. > > E) The message has a signature by a Third-Party domain. If all you are doing is spam control a signature from an accountable third party is sufficient and you would not need to check policy. If bank of america sends a message to the list where it gets munged and resigned that is going to be acceptable at some level. If we want the ability to insist on being able to distinguish this case we will need to do a lot more. I would much prefer to wait till a recharter. In particular I think it will be much easier to do that type of policy after the email infrastructure has made accomodation to DKIM. > F) The signer seemed to be unrelated to the > From/Sender/Whatever headers; > > G) The signature covered an "unusual" selection of headers; That would be another example of not sufficient. > H) There were several signatures, of which some passed and > some failed; Failed signatures are ignored. > A Policy Record might well clear up some (probably not all) > of such cases. > Moreover, experience will throw up new scams that the Bad > Guys will invent, and so it may become necessary to add new > kinds of information to Policy records that we have not even > thought of yet. So, to that extent, their notation needs to > be extensible. Some of which will be something DKIM needs to deal with, some will not. Phill _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 12 15:34:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I94QQ-0001TF-Sn for ietf-dkim-archive@lists.ietf.org; Thu, 12 Jul 2007 15:34:06 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I94QM-0002dx-Cd for ietf-dkim-archive@lists.ietf.org; Thu, 12 Jul 2007 15:34:06 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6CJWJOZ017940; Thu, 12 Jul 2007 12:32:24 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6CJW2Tp017897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Jul 2007 12:32:02 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id D3BD941432; Thu, 12 Jul 2007 12:32:04 -0700 (PDT) In-Reply-To: <198A730C2044DE4A96749D13E167AD37012F6D64@MOU1WNEXMB04.vcorp.ad.vrsn.com> References: <198A730C2044DE4A96749D13E167AD37012F6D64@MOU1WNEXMB04.vcorp.ad.vrsn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36CB808B-1748-43BF-82B5-010D1800A853@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt Date: Thu, 12 Jul 2007 12:22:27 -0700 To: "Hallam-Baker, Phillip" X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 On Jul 12, 2007, at 7:34 AM, Hallam-Baker, Phillip wrote: >>> E) The message has a signature by a Third-Party domain. > > If all you are doing is spam control a signature from an > accountable third party is sufficient and you would not need to > check policy. If bank of america sends a message to the list where > it gets munged and resigned that is going to be acceptable at some > level. Not exactly. A Third-Party signature coincident with the SMTP client excludes replay abuse, which is likely problematic with respect to spam. > If we want the ability to insist on being able to distinguish this > case we will need to do a lot more. I would much prefer to wait > till a recharter. In particular I think it will be much easier to > do that type of policy after the email infrastructure has made > accomodation to DKIM. Third-Party authorization should not be delayed, nor is there a reason to wait. There are three fairly important issues dramatically affected by the methods DKIM allows to authorize Third-Party domains. 1) Replay Abuse 2) Key Security 3) DSN handling This is detailed in an extension to SSP, which slightly modifies the current SSP proposal: http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-01.txt Third-Party authorizations by-name safely scales. This authorization strategy permits a signing domain to readily coincide with that of the SMTP client. When the authorized signing domain is coincident with an SMTP client within the same domain, replay abuse is precluded as a risk. The ensures adequate resources are available to handle exceptions where there would be risk of replay abuse. By using an authorization by-name scheme, rather than exchanging keys for this purpose, the impact of a compromised key is limited to just that domain. Reports of a compromise would not list every selector/ domain of where a public half of this service provider's keys had been published. Without an authorization by-name SSP record, every customer of the service provider wishing to authorize the service might need to be included within such a report. This type of report would be devastating news for DKIM. DKIM keys will be distributed to several servers connecting to the Internet, and are fairly vulnerable as a result. The use of transparent authorization techniques must be discouraged, as this will represent a significant problem when dealing with security breaches or even establishing best practices. When a record is signed by a Third-Party domain, versus not being signed, this is a natural place to first query for a TPA-SSP record, rather than just an SSP record. The use of a wildcard at this location eliminates any subsequent SSP record query. This authorization by-name technique safely scales, unlike any IP address path registration scheme. This authorization by-name helps curtail possible replay abuse as well. Authorization by-name also greatly simplifies the process an email-address domain administrator confronts when they desire to authorize a service provider. This also greatly limits the email-address domains exposure to possible security breaches as well. As a bonus, by including a signed header contained the MAILFROM address, authorization by-name can also ensure that DSNs of differing domains are safe to submit. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 14 14:56:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9mnY-0004tV-0v for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 14:56:56 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9mnT-000139-JE for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 14:56:56 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6EItKY7023511; Sat, 14 Jul 2007 11:55:26 -0700 Received: from [10.255.64.11] (m015f36d0.tmodns.net [208.54.95.1]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6EIt3KV023452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Jul 2007 11:55:05 -0700 Message-ID: <46991C15.7000405@dcrocker.net> Date: Sat, 14 Jul 2007 14:55:17 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Subject: [ietf-dkim] ISSUE: dkim-overview -- normative statements X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Folks, The overview document states that it is seeking Informational RFC status. Further, it does not include the usual citation and statement that normative vocabulary is used to assert normative requirements. Nonetheless, the document has quite a number of apparently normative statements -- including some in uppercase -- such as: > 2.2. Email Infrastructure Agents > > It is expected that the most common venue for a DKIM implementation > will be within the infrastructure of an organization's email service, > such as a department or a boundary MTA. ... > Outbound: An MSA or Outbound MTA should allow for the automatic > verification of the MTA configuration such that the MTA can ... > An outbound MTA should be aware that users may employ MUAs that > add their own signatures and be prepared to take steps ... > Intermediaries: An email intermediary is both an inbound and > outbound MTA. Each of the requirements outlined in the > sections relating to MTAs apply. If the intermediary modifies > a message in a way that breaks the signature, the intermediary > > + SHOULD deploy abuse filtering measures on the inbound mail, > and > > + MAY remove all signatures that will be broken and > 2.5.3.3. Boundary Enforcement > > In order for an assessment module to trust the information it > receives about verification (e.g., Authentication-Results headers), > it MUST eliminate verification information originating from outside > the ADMD in which the assessment mechanism operates. As a matter of This seems anomalous and raises a line of questions: If the apparently normative statements are actually trying to be normative and are reasonable, has the intent of the document changed? Even though I've written some portion of the language in the document, I have mixed feelings about this issue. Some of the apparently-normative statements I like and some I don't -- and I don't know which ones I wrote, so that's not the issue. Beyond being a summary of DKIM, the document also has become something of a higher-level "system specification". As such, some of the normative language really pertains to the higher-level integration of DKIM into an operational email service and well could be extremely useful for guiding design, implementation and deployment of DKIM. I think that's a good thing, but I think we need to resolve whether this document is making architectural, normative specification or whether it is providing tutorial exemplars. Unfortunately I don't think this can be resolved by a simple assertion of an underlying principle. I think we need to look at the actual language in the document and decide what is important for the current work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 14 16:03:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9npg-0004aK-Lc for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 16:03:12 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9npc-0002fk-8S for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 16:03:12 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6EK1dkx006237; Sat, 14 Jul 2007 13:01:44 -0700 Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6EK1Vsv006197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Jul 2007 13:01:31 -0700 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id l6EK1dbK085963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 14 Jul 2007 13:01:40 -0700 (MST) (envelope-from paul.hoffman@domain-assurance.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <46991C15.7000405@dcrocker.net> References: <46991C15.7000405@dcrocker.net> Date: Sat, 14 Jul 2007 13:01:34 -0700 To: ietf-dkim@mipassoc.org From: Paul Hoffman Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Many thanks to Dave for bringing this up. At 2:55 PM -0400 7/14/07, Dave Crocker wrote: >The overview document states that it is seeking Informational RFC >status. Further, it does not include the usual citation and >statement that normative vocabulary is used to assert normative >requirements. > >Nonetheless, the document has quite a number of apparently normative >statements -- including some in uppercase -- such as: >. . . > >This seems anomalous and raises a line of questions: > > If the apparently normative statements are actually trying to be >normative and are reasonable, has the intent of the document changed? > > Even though I've written some portion of the language in the >document, I have mixed feelings about this issue. Some of the >apparently-normative statements I like and some I don't -- and I >don't know which ones I wrote, so that's not the issue. > > Beyond being a summary of DKIM, the document also has become >something of a higher-level "system specification". As such, some >of the normative language really pertains to the higher-level >integration of DKIM into an operational email service and well could >be extremely useful for guiding design, implementation and >deployment of DKIM. I think that's a good thing, but I think we >need to resolve whether this document is making architectural, >normative specification or whether it is providing tutorial >exemplars. > I think it would be fine to make this a standards-track document with normative language. --Paul Hoffman, Director --Domain Assurance Council _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 14 17:43:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9pOI-0008Tn-Fi for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 17:43:02 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9pOD-0005Zx-PS for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 17:43:02 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6ELfSFY024755; Sat, 14 Jul 2007 14:41:33 -0700 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6ELfK9Y024724 for ; Sat, 14 Jul 2007 14:41:21 -0700 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 14 Jul 2007 23:41:29 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPjemEaQ/uCKh2dsb2JhbACBSo1tAQEJDiw X-IronPort-AV: i="4.16,539,1175464800"; d="scan'208"; a="148067697:sNHT23079432" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6ELfSiW027280; Sat, 14 Jul 2007 23:41:28 +0200 Received: from adsl-247-6-fixip.tiscali.ch (ams3-vpn-dhcp4226.cisco.com [10.61.80.129]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ELfRkt002104; Sat, 14 Jul 2007 21:41:28 GMT Message-ID: <46994301.3030303@cisco.com> Date: Sat, 14 Jul 2007 23:41:21 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements References: <46991C15.7000405@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=101; t=1184449288; x=1185313288; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[ietf-dkim]=20ISSUE=3A=20=20dkim-overview=20--=20norm ative=20statements |Sender:=20; bh=ml0qaYtp+fgHAz6Eq2bqj8RjM/fo8Ayabzm9+zARRH8=; b=ox2ddRN4WKgaBAwp5r13qw4YQSd7LADfFCv79YdNv/s5vSQc1WclZCI0vUNDObI4ZVRkXD5A PtU+ujV2EtBSXihZTMTRo7FVYNtnqqlZl+qQ8jEIMVCR3kPn7kPTeoNf; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db An overview is not the place for normative statements. Can we discuss this in person in Chicago? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sat Jul 14 18:24:30 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9q2Q-000659-6Y for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 18:24:30 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9q2L-0006Tw-QH for ietf-dkim-archive@lists.ietf.org; Sat, 14 Jul 2007 18:24:30 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6EMNRPu002107; Sat, 14 Jul 2007 15:23:27 -0700 Received: from [10.225.0.32] (m015f36d0.tmodns.net [208.54.95.1]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6EMNG1W002074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 15:23:18 -0700 Message-ID: <46994CE3.3010601@dcrocker.net> Date: Sat, 14 Jul 2007 18:23:31 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements References: <46991C15.7000405@dcrocker.net> <46994301.3030303@cisco.com> In-Reply-To: <46994301.3030303@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 1.8 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Eliot Lear wrote: > An overview is not the place for normative statements. Can we discuss > this in person in Chicago? Eliot, et al, I think your response highlights the dilemma: There is the title (and the original intent) and there is (possibly) a different reality to the current content. On the theory that the current content is, in fact, useful, something needs to be reconciled. That's why I noted that the content has moved more towards an integrated system-level (or service-level) description of DKIM. Take a look over the document for the various must/should/may language and note that much of it seems like reasonable directives to folks seeking to integrate a DKIM service component into their email software and operations. That might well qualify as a service specification, along the lines that the IETF frequently publishes as standards-track. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 15 01:40:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9wpw-0005Oz-Ra for ietf-dkim-archive@lists.ietf.org; Sun, 15 Jul 2007 01:40:04 -0400 Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9wps-0005T6-31 for ietf-dkim-archive@lists.ietf.org; Sun, 15 Jul 2007 01:40:04 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6F5c6BS010693; Sat, 14 Jul 2007 22:38:16 -0700 Received: from fugu.mtcc.com (mtcc.com [64.142.29.208]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6F5bxn6010667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 14 Jul 2007 22:37:59 -0700 Received: from [192.168.0.101] (63-170-118-67.du.volcano.net [63.170.118.67]) (authenticated bits=0) by fugu.mtcc.com (8.13.8/8.13.8) with ESMTP id l6F5c0Pj009205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jul 2007 22:38:02 -0700 Message-ID: <4699B3BB.6030302@mtcc.com> Date: Sat, 14 Jul 2007 22:42:19 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.12) Gecko/20070509 Thunderbird/1.5.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements References: <46991C15.7000405@dcrocker.net> In-Reply-To: <46991C15.7000405@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; header.From=mike@mtcc.com; dkim=neutral ( ssp=~; ); X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Dave Crocker wrote: > Folks, > > The overview document states that it is seeking Informational RFC > status. Further, it does not include the usual citation and statement > that normative vocabulary is used to assert normative requirements. I'd say that this is a poor idea as it becomes rather unclear who is authoritative when you have potential conflicts as in: >> sections relating to MTAs apply. If the intermediary modifies >> a message in a way that breaks the signature, the intermediary >> >> + SHOULD deploy abuse filtering measures on the inbound mail, >> and >> >> + MAY remove all signatures that will be broken and RFC4871 which sez: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. I really don't see why we should be setting ourselves up for this kind of conflict. To my mind, this document has been ever chomping at the bit to be a BCP. I'm all in favor of a BCP, but only when we really know those B's, C's, and P's are. Inserting new normative language about how one should use DKIM beyond what's in 4871 seems rather premature to me. Mike > > and > >> 2.5.3.3. Boundary Enforcement >> >> In order for an assessment module to trust the information it >> receives about verification (e.g., Authentication-Results headers), >> it MUST eliminate verification information originating from outside >> the ADMD in which the assessment mechanism operates. As a matter of > > > This seems anomalous and raises a line of questions: > > If the apparently normative statements are actually trying to be > normative and are reasonable, has the intent of the document changed? > > Even though I've written some portion of the language in the > document, I have mixed feelings about this issue. Some of the > apparently-normative statements I like and some I don't -- and I don't > know which ones I wrote, so that's not the issue. > > Beyond being a summary of DKIM, the document also has become > something of a higher-level "system specification". As such, some of > the normative language really pertains to the higher-level integration > of DKIM into an operational email service and well could be extremely > useful for guiding design, implementation and deployment of DKIM. I > think that's a good thing, but I think we need to resolve whether this > document is making architectural, normative specification or whether > it is providing tutorial exemplars. > > Unfortunately I don't think this can be resolved by a simple assertion > of an underlying principle. > > I think we need to look at the actual language in the document and > decide what is important for the current work. > > d/ > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 15 03:54:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9ywH-0000fA-7R for ietf-dkim-archive@lists.ietf.org; Sun, 15 Jul 2007 03:54:45 -0400 Received: from sb7.songbird.com ([208.184.79.137] helo=mail.songbird.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9ywD-0007ex-JQ for ietf-dkim-archive@lists.ietf.org; Sun, 15 Jul 2007 03:54:45 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6F7rhWd029134; Sun, 15 Jul 2007 00:53:48 -0700 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6F7rW72029048 for ; Sun, 15 Jul 2007 00:53:33 -0700 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Jul 2007 09:53:41 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMJumUaQ/uCLh2dsb2JhbACBSmE3jFkBAQkKJw X-IronPort-AV: i="4.16,540,1175464800"; d="scan'208,217"; a="148074400:sNHT46525872" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6F7reIv019099; Sun, 15 Jul 2007 09:53:40 +0200 Received: from adsl-247-5-fixip.tiscali.ch (ams3-vpn-dhcp4280.cisco.com [10.61.80.183]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6F7rekt016801; Sun, 15 Jul 2007 07:53:40 GMT Message-ID: <4699D27C.5080708@cisco.com> Date: Sun, 15 Jul 2007 09:53:32 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: dcrocker@bbiw.net Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements References: <46991C15.7000405@dcrocker.net> <46994301.3030303@cisco.com> <46994CE3.3010601@dcrocker.net> In-Reply-To: <46994CE3.3010601@dcrocker.net> DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4424; t=1184486021; x=1185350021; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[ietf-dkim]=20ISSUE=3A=20=20dkim-overview=20--=20norm ative=20statements |Sender:=20; bh=36MF18NzmUN3z43zAIac85dzQZCCcE/jxHU5KVrNQZw=; b=mYJ8aWnq22F6d9ZTNJJqFJzUCtB2tWSeYCdS7m+OP2zCZCKOoH3BtuIX12tm7fXRR443Yghq gykgr2gLJhFEMhr4SgOU+lrtA6F2xFDA1e9utx6xCvSewEc4YQHbiuhv; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1669617174==" Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. --===============1669617174== Content-Type: multipart/alternative; boundary="------------070101070601020107000902" This is a multi-part message in MIME format. --------------070101070601020107000902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dave, I agree with Mike Thomas. As a general rule I believe you are better off with fewer documents with normative text than more. There is a lot of text around mailing lists that comes dangerously close to text in the SSP draft (see -overview Section 2.5, and -ssp, Section 5.1). The last thing we want are two documents that mandate behavior in the same components in what could end up being subtly different ways. It may be useful to have a BCP or an overview, but the scope of that document must be made clear, and should not overlap with standards specifications. The use of normative language in the draft today is IMHO inappropriate even for a BCP, and in some cases is overly broad. Here are two examples: * In section 2.1 you talk about memory models and keeping private keys private. I think that states the obvious, while at the same time going way down the implementation path. If you're going to state the obvious, do so once and not at only some of numerous opportunities for a key to be exposed. Furthermore, this text goes into implementation design. That's not BCP territory, IMHO. * In Section 2.2 you talk about requiring secure zone updates without really defining what you mean. Are you, for instance, talking about DNS registrars needing to use SSL? Is a login password good enough or is that not strong enough? Is DDNS useful in this context? If so, how? If not why not? (I'd argue the latter, but there's no argument in there at all right now.) Given these issues, how would you want to proceed? Finally, because it's clear that a fair amount more work is needed on this document, and as SSP is progressing, I think it would be prudent to be mindful of SSP, and to reconsider gating this document to SSP, assuming we keep moving forward on the latter. Eliot --------------070101070601020107000902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dave,

I agree with Mike Thomas.

As a general rule I believe you are better off with fewer documents with normative text than more. There is a lot of text around mailing lists that comes dangerously close to text in the SSP draft (see -overview Section 2.5, and -ssp, Section 5.1).  The last thing we want are two documents that mandate behavior in the same components in what could end up being subtly different ways.

It may be useful to have a BCP or an overview, but the scope of that document must be made clear, and should not overlap with standards specifications.  The use of normative language in the draft today is IMHO inappropriate even for a BCP, and in some cases is overly broad.  Here are two examples:

  • In section 2.1 you talk about memory models and keeping private keys private.  I think that states the obvious, while at the same time going way down the implementation path.  If you're going to state the obvious, do so once and not at only some of numerous opportunities for a key to be exposed.  Furthermore, this text goes into implementation design.  That's not BCP territory, IMHO.
  • In Section 2.2 you talk about requiring secure zone updates without really defining what you mean.  Are you, for instance, talking about DNS registrars needing to use SSL?  Is a login password good enough or is that not strong enough?  Is DDNS useful in this context?  If so, how?  If not why not?  (I'd argue the latter, but there's no argument in there at all right now.)
Given these issues, how would you want to proceed?

Finally, because it's clear that a fair amount more work is needed on this document, and as SSP is progressing, I think it would be prudent to be mindful of SSP, and to reconsider gating this document to SSP, assuming we keep moving forward on the latter.

Eliot

--------------070101070601020107000902-- --===============1669617174== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html --===============1669617174==-- From ietf-dkim-bounces@mipassoc.org Sun Jul 15 11:54:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IA6QH-0000IY-DY for ietf-dkim-archive@lists.ietf.org; Sun, 15 Jul 2007 11:54:13 -0400 Received: from sb7.songbird.com ([208.184.79.137] helo=mail.songbird.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IA6QC-00069R-VE for ietf-dkim-archive@lists.ietf.org; Sun, 15 Jul 2007 11:54:13 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6FFrCml021387; Sun, 15 Jul 2007 08:53:18 -0700 Received: from cox.com (post6.cox.com [24.248.74.39]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6FFr4L3021332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 15 Jul 2007 08:53:05 -0700 Received: from ([192.168.74.254]) by post6.cox.com with ESMTP id KP-VXK84.199198688; Sun, 15 Jul 2007 11:52:51 -0400 Received: from CATL0MS21.CORP.COX.COM ([10.64.210.21]) by catl0ms22.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Jul 2007 11:52:51 -0400 Received: from CATL0MS02.corp.cox.com ([10.62.210.88]) by CATL0MS21.CORP.COX.COM with Microsoft SMTPSVC(6.0.3790.3959); Sun, 15 Jul 2007 11:52:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [ietf-dkim] ISSUE: dkim-overview -- normative statements Date: Sun, 15 Jul 2007 11:50:01 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] ISSUE: dkim-overview -- normative statements Thread-Index: AcfGozcWVV5EyzM3SmarOM1UB1H09QAVJasv References: <46991C15.7000405@dcrocker.net> <4699B3BB.6030302@mtcc.com> From: To: , X-OriginalArrivalTime: 15 Jul 2007 15:52:50.0872 (UTC) FILETIME=[32BC0380:01C7C6F8] X-Songbird: Clean, Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.songbird.com id l6FFr4L3021332 Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Its not a conflict, the document in question states an intermediate MTA MAY remove broken sigs. The RFC states "Signers SHOULD NOT remove any DKIM-Signature header" an intermediate MTA may or may not be a signer, its not the issue being addressed thanks, Bill -----Original Message----- From: ietf-dkim-bounces@mipassoc.org on behalf of Michael Thomas Sent: Sun 7/15/2007 1:42 AM To: dcrocker@bbiw.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements Dave Crocker wrote: > Folks, > > The overview document states that it is seeking Informational RFC > status. Further, it does not include the usual citation and statement > that normative vocabulary is used to assert normative requirements. I'd say that this is a poor idea as it becomes rather unclear who is authoritative when you have potential conflicts as in: >> sections relating to MTAs apply. If the intermediary modifies >> a message in a way that breaks the signature, the intermediary >> >> + SHOULD deploy abuse filtering measures on the inbound mail, >> and >> >> + MAY remove all signatures that will be broken and RFC4871 which sez: Signers SHOULD NOT remove any DKIM-Signature header fields from messages they are signing, even if they know that the signatures cannot be verified. I really don't see why we should be setting ourselves up for this kind of conflict. To my mind, this document has been ever chomping at the bit to be a BCP. I'm all in favor of a BCP, but only when we really know those B's, C's, and P's are. Inserting new normative language about how one should use DKIM beyond what's in 4871 seems rather premature to me. Mike > > and > >> 2.5.3.3. Boundary Enforcement >> >> In order for an assessment module to trust the information it >> receives about verification (e.g., Authentication-Results headers), >> it MUST eliminate verification information originating from outside >> the ADMD in which the assessment mechanism operates. As a matter of > > > This seems anomalous and raises a line of questions: > > If the apparently normative statements are actually trying to be > normative and are reasonable, has the intent of the document changed? > > Even though I've written some portion of the language in the > document, I have mixed feelings about this issue. Some of the > apparently-normative statements I like and some I don't -- and I don't > know which ones I wrote, so that's not the issue. > > Beyond being a summary of DKIM, the document also has become > something of a higher-level "system specification". As such, some of > the normative language really pertains to the higher-level integration > of DKIM into an operational email service and well could be extremely > useful for guiding design, implementation and deployment of DKIM. I > think that's a good thing, but I think we need to resolve whether this > document is making architectural, normative specification or whether > it is providing tutorial exemplars. > > Unfortunately I don't think this can be resolved by a simple assertion > of an underlying principle. > > I think we need to look at the actual language in the document and > decide what is important for the current work. > > d/ > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Jul 16 03:16:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAKop-0003rA-Dp for ietf-dkim-archive@lists.ietf.org; Mon, 16 Jul 2007 03:16:31 -0400 Received: from mail.songbird.com ([208.184.79.10] helo=sb7.songbird.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAKok-0000x5-US for ietf-dkim-archive@lists.ietf.org; Mon, 16 Jul 2007 03:16:31 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6G7EGWp020307; Mon, 16 Jul 2007 00:14:24 -0700 Received: from [192.168.0.3] (adsl-68-122-41-246.dsl.pltn13.pacbell.net [68.122.41.246]) (authenticated bits=0) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6G7E5Ju020244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jul 2007 00:14:10 -0700 Message-ID: <46998505.7090807@dcrocker.net> Date: Sat, 14 Jul 2007 22:23:01 -0400 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Michael Thomas Subject: Re: [ietf-dkim] Choices about Practice vs. Publication References: <4691300D.5000001@dcrocker.net> <46913920.5020200@mtcc.com> In-Reply-To: <46913920.5020200@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: dcrocker@bbiw.net, ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Michael Thomas wrote: > Dave Crocker wrote: >> I think a simple and appropriate model, here, is that the >> receive-side should be given information that permits it to detect >> external attacks -- that is, misbehaviors by actors external to the >> origin-side. ... > In which case, the bob and jane @ earthlink problem is really earthlink's > to deal with. I think that's entirely appropriate; it is completely within > earthlink's capability to, say, use SMTP AUTH to gate users to deal with > this attack. You might be referring to a different issue, but I think the i= parameter makes this particular issue moot. Might have been an interesting discussion about 2 years ago, but not so much now. >> 2. Practice vs. Publication >> Classically, this is the "what vs. how" distinction. >> >> What is the information that the 'sender' or signer wants to >> communicate to the receiver? Distinct from this is the means by which >> it is communicated. >> >> The two obvious choices for communicating anything involving DKIM are: >> >> a) DNS publication, versus >> >> b) inclusion in the signed message, either as an enhancement >> to an existing header field, or as a new field. > > There's really a third dimension too: the "unsigned" message problem. If the message is unsigned, then it is not a candidate for carrying DKIM information, is it? Note that my list was about *mechanisms* for carrying information, not (at this point) about what might dictate the choice. > The subdivision of labor with DKIM has pretty much been: if it's > something that constrains a key, then it goes in the DNS record. > Everything else goes in the signature header. This seems pretty > clean. Well, you are certainly stating a very simple and clear rule. However I don't recall that being discussed by the working group or there being any clear understanding among the group that that is the design policy. In any event, what my interaction with Steve did was suggest a related, but somewhat different policy basis. Note that an SSP record in the DNS, to cover unsigned messages, does not fit your policy rule. >> Steve pointed out to me that a basic challenge, here, is that DKIM >> does not define a signature as meaning that the signer is asserting >> the truthfulness of any particular bit of information in the message. >> That's the inherent difference between the mild "taking >> responsibility" semantics that we have given to a DKIM signature, >> versus "asserting correctness" or the like. >> >> My suggestion to deal with this is to define the basic DKIM >> sematnic that all DKIM-* headers are asserted to be valid, if they are >> included in the signature. > I'm not really sure where you're going with this, and I don't > think I like the implications. If a signer asserts something, it's > motivation for asserting it has to always be viewed with the > possibility of being gamed. So I don't know what "valid" Concern for being gamed is certainly required. > means through that lens. Useful information to a receiver can > only be of the "negative" variety; economists probably have > language for this, but information that there is no incentive for > the signer to lie about. Typically these are things that constrain > the degrees of freedom rather than increase them, which is > exactly what the current crop of tags in DKIM do. "Useful information to a receiver can only be of the "negative" variety" strikes me as a pretty remarkable assertion, given that DKIM is far more about establishing positive trust than negative. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Jul 16 06:05:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANRw-0000Ec-FG for ietf-dkim-archive@lists.ietf.org; Mon, 16 Jul 2007 06:05:05 -0400 Received: from mail.songbird.com ([208.184.79.10] helo=sb7.songbird.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IANRr-0004NJ-Su for ietf-dkim-archive@lists.ietf.org; Mon, 16 Jul 2007 06:05:04 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6GA3v50018643; Mon, 16 Jul 2007 03:04:02 -0700 Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6GA3mH3018616 for ; Mon, 16 Jul 2007 03:03:48 -0700 Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster#pop3*clerew$man*ac&uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.243) id 469b428c.32e8.305 for ietf-dkim@mipassoc.org; Mon, 16 Jul 2007 11:03:56 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id l6GA3SHg025502 for ; Mon, 16 Jul 2007 11:03:29 +0100 (BST) To: DKIM Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements References: <46991C15.7000405@dcrocker.net> Message-ID: Date: Mon, 16 Jul 2007 11:03:28 +0100 From: "Charles Lindsey" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 In-Reply-To: User-Agent: Opera M2/8.01 (SunOS, build 1204) X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sb7.songbird.com id l6GA3v50018643 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a On Sat, 14 Jul 2007 21:01:34 +0100, Paul Hoffman =20 wrote: > Many thanks to Dave for bringing this up. > > At 2:55 PM -0400 7/14/07, Dave Crocker wrote: >> The overview document states that it is seeking Informational RFC =20 >> status. Further, it does not include the usual citation and statement = =20 >> that normative vocabulary is used to assert normative requirements. >> >> Nonetheless, the document has quite a number of apparently normative =20 >> statements -- including some in uppercase -- such as: >> . . . >> >> This seems anomalous and raises a line of questions: >> >> If the apparently normative statements are actually trying to be =20 >> normative and are reasonable, has the intent of the document changed? >> >> Even though I've written some portion of the language in the =20 >> document, I have mixed feelings about this issue. Some of the =20 >> apparently-normative statements I like and some I don't -- and I don't= =20 >> know which ones I wrote, so that's not the issue. >> >> Beyond being a summary of DKIM, the document also has become =20 >> something of a higher-level "system specification". As such, some of= =20 >> the normative language really pertains to the higher-level integration= =20 >> of DKIM into an operational email service and well could be extremely = =20 >> useful for guiding design, implementation and deployment of DKIM. I =20 >> think that's a good thing, but I think we need to resolve whether this= =20 >> document is making architectural, normative specification or whether i= t =20 >> is providing tutorial exemplars. >> > > I think it would be fine to make this a standards-track document with =20 > normative language. I disagree. The purpose of an "Overview" is to give an informal summary o= f =20 the effect, and especially the reasoning and motivation for, a collection= =20 of standards. So it may well outline what the standards do, and indicate = =20 the sort of normative provisions they would make (which can include =20 indication of whether such provisions are MUST/SHOULD/MAY). But it should include somewhere wording such as: "This document provides an overview of the DKIM collection of relat= ed =20 standards, indicating how they are intended to work together to produce =20 [list of desirable effects]. But this document is not normative itself; =20 {RFCxxx], [RFCyyy] and [RFCzzz] should be consulted for the detailed =20 normative requirements." --=20 Charles=A0H.=A0Lindsey=A0---------At=A0Home,=A0doing=A0my=A0own=A0thing--= ---------------------- Tel:=A0+44=A0161=A0436=A06131=A0 =20 =A0=A0=A0Web:=A0http://www.cs.man.ac.uk/~chl Email:=A0chl@clerew.man.ac.uk=A0=A0=A0=A0=A0=A0Snail:=A05=A0Clerewood=A0A= ve,=A0CHEADLE,=A0SK8=A03JU,=A0U.K. PGP:=A02C15F1A9=A0=A0=A0=A0=A0=A0Fingerprint:=A073=A06D=A0C2=A051=A093=A0= A0=A001=A0E7=A065=A0E8=A064=A07E=A014=A0A4=A0AB=A0A5 _______________________________________________ NOTE WELL: This list operates according to=20 http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Jul 16 12:48:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATkJ-00012b-Tz for ietf-dkim-archive@lists.ietf.org; Mon, 16 Jul 2007 12:48:27 -0400 Received: from mail.songbird.com ([208.184.79.10] helo=sb7.songbird.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IATkF-0002gz-G5 for ietf-dkim-archive@lists.ietf.org; Mon, 16 Jul 2007 12:48:27 -0400 Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6GGke75014627; Mon, 16 Jul 2007 09:46:48 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6GGkU1b014505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 16 Jul 2007 09:46:30 -0700 Received: from [IPv6:::1] (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 9CB5C4145F; Mon, 16 Jul 2007 09:46:37 -0700 (PDT) In-Reply-To: References: <46991C15.7000405@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <06D94CCE-506A-4B5D-9ADC-7A436CB8391C@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements Date: Mon, 16 Jul 2007 09:46:39 -0700 To: Charles Lindsey X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Jul 16, 2007, at 3:03 AM, Charles Lindsey wrote: > On Sat, 14 Jul 2007 21:01:34 +0100, Paul Hoffman > wrote: > >> Many thanks to Dave for bringing this up. >> >> At 2:55 PM -0400 7/14/07, Dave Crocker wrote: >> >> I think it would be fine to make this a standards-track document >> with normative language. > > I disagree. The purpose of an "Overview" is to give an informal > summary of the effect, and especially the reasoning and motivation > for, a collection of standards. So it may well outline what the > standards do, and indicate the sort of normative provisions they > would make (which can include indication of whether such provisions > are MUST/SHOULD/MAY). > > But it should include somewhere wording such as: > > "This document provides an overview of the DKIM collection of > related standards, indicating how they are intended to work > together to produce [list of desirable effects]. But this document > is not normative itself; {RFCxxx], [RFCyyy] and [RFCzzz] should be > consulted for the detailed normative requirements." An overview should not be normative. Agreed. At some point, corrections to RFCs describing the protocol might be required, or a BCP document to explain desired methods to address various issues might be appropriate, but much later. This overview has not been reviewed from a perspective of noting whether it creates new or conflicting normative requirements. Expectations were just the opposite. As a side note, would it be possible to reference the TPA-SSP instead of the DOSP draft in the working drafts section on the DKIM website? TPA-SSP will be easier to understand. You should have the XML and HTML versions of this draft. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Tue Jul 17 01:56:13 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAg2d-0001gl-6h for ietf-dkim-archive@lists.ietf.org; Tue, 17 Jul 2007 01:56:11 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAg2Z-0000fK-Fr for ietf-dkim-archive@lists.ietf.org; Tue, 17 Jul 2007 01:56:11 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6H5saMN027070; Mon, 16 Jul 2007 22:54:50 -0700 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6H5sBvo026930 for ; Mon, 16 Jul 2007 22:54:11 -0700 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2007 07:54:20 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAN/1m0aQ/uCLh2dsb2JhbACPPgIJCic X-IronPort-AV: i="4.16,545,1175464800"; d="eml'208?scan'208,208"; a="148203944:sNHT49982046" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6H5sJ8N030359 for ; Tue, 17 Jul 2007 07:54:19 +0200 Received: from adsl-247-4-fixip.tiscali.ch (ams3-vpn-dhcp213.cisco.com [10.61.64.213]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6H5sIkt007324 for ; Tue, 17 Jul 2007 05:54:19 GMT Message-ID: <469C5982.9000300@cisco.com> Date: Tue, 17 Jul 2007 07:54:10 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: IETF-DKIM Content-Type: multipart/mixed; boundary="------------020402010403070902010802" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9428; t=1184651659; x=1185515659; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20[Fwd=3A=20secdir=20review=20of=20draft-ietf-dkim-ssp-requirem ents-04] |Sender:=20; bh=bkGjIqrtK4e5JbGtpd8UidG4FbE5JiWJw4T4H94yW7Y=; b=SfDIgg+/P8QyYi/8ljghMRDZnMXepqIWljdYuY4U+1p3lITMPi6uxEdTJeBoljngYrVvxzh8 9jAF4Zo3uEPNmjbk/PLiBxrJwAUngBxZ1LHZIp79QDhNDlx2hJYKMQyM; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Songbird: Clean, Clean Subject: [ietf-dkim] [Fwd: secdir review of draft-ietf-dkim-ssp-requirements-04] X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.1 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 This is a multi-part message in MIME format. --------------020402010403070902010802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI --------------020402010403070902010802 Content-Type: message/rfc822; name="secdir review of draft-ietf-dkim-ssp-requirements-04.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="secdir review of draft-ietf-dkim-ssp-requirements-04.eml" X-Account-Key: account2 X-Mozilla-Keys: Received: from xbh-ams-331.emea.cisco.com ([144.254.231.71]) by xmb-ams-335.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 23:28:07 +0200 Received: from xbh-sjc-231.amer.cisco.com ([128.107.191.100]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 23:28:07 +0200 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 14:28:05 -0700 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2007 14:28:05 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6GLS523017917; Mon, 16 Jul 2007 14:28:05 -0700 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6GLS0Ss022447; Mon, 16 Jul 2007 21:28:05 GMT Received: from stiedprmman1.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by sj-inbound-a.cisco.com with ESMTP; 16 Jul 2007 14:28:02 -0700 X-from-outside-Cisco: 156.154.16.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAL9/m0acmhCRkmdsb2JhbACPPAEBAgcCCCc X-IronPort-AV: i="4.16,543,1175497200"; d="scan'208"; a="24945290:sNHT23337150" Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAY6R-0001qv-R3; Mon, 16 Jul 2007 17:27:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAY6O-0001mh-L2; Mon, 16 Jul 2007 17:27:32 -0400 Received: from rwcrmhc14.comcast.net ([216.148.227.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAY6K-000337-5d; Mon, 16 Jul 2007 17:27:32 -0400 Received: from harrington73653 (c-24-128-104-207.hsd1.nh.comcast.net[24.128.104.207]) by comcast.net (rwcrmhc14) with SMTP id <20070716212724m1400m18che>; Mon, 16 Jul 2007 21:27:27 +0000 From: "David Harrington" To: , , "'Sam Hartman'" , Date: Mon, 16 Jul 2007 17:27:41 -0400 Message-ID: <00b801c7c7f0$26818790$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfG2BiFcQndy6ZxRG+afWNlwa4xOgBBrBsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: "'Michael Thomas'" , "'IETF discussion list'" Subject: secdir review of draft-ietf-dkim-ssp-requirements-04 X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ietf-bounces@ietf.org Authentication-Results: sj-dkim-2; header.From=ietfdbh@comcast.net; dkim=neutral Return-Path: ietf-bounces@ietf.org X-OriginalArrivalTime: 16 Jul 2007 21:28:05.0731 (UTC) FILETIME=[3289AB30:01C7C7F0] Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Security review: draft-ietf-dkim-ssp-requirements-04 discusses requirements for the DKIM signing practices protocol. I felt the discussion of security issues for DKIM signing was very light. The Security Considerations section was also too light. My advice to the security area directors is that, before publication, this draft should document stronger security requirements for the DKIM signing protocol. This document should include an enumeration of the potential threats, as described in BCP 72 (RFC3552), followed by a discussion of the requirements that must be met by DKIM signing to mitigate those threats. - a few specific comments related to security issues: 1) section 5.1 discusses discovery requirements. bullet#1 says the author is the first party sender of a message. After reading this, I had the question "author of what?" The preceding text only says there must be a means of obtaining information. It doesn't discuss any particular approach to getting the information, so I am not sure what is being authored. 2) section 5.1, bullet #4 says the WG might not be able to reach a consensus on a solution that completes within a deterministic number of steps, and if they do not reach consensus, then they MUST document the relevant security considerations. Even if they DO reach consensus, they will need to document the security considerations. I'm not sure how they will document the security considerations of not reaching consensus. I think there are range of topics mixed into bullet#4, and they need to be broken out before security for these things can be considered. 3) section 5.3 bullet #2 calls for a concise linkage between the identity in the From field and the DKIM i= tag. Isn't the concise linkage that you need here some type of identity authentication? If not, how do you know the mapping is actually valid? 4) security requirement#1 - What must SSP do to prevent such DoS attacks? what must SSP do to prevent being vulnerable to such DoS attacks? Note that these are two separate questions with potentially different mitigation strategies. 5) security requirement#2 - what must SSP do to prevent such attacks? Keeping exchanges small might help, but how about establishing a secure channel, and using data origin authentication, and message integrity checking, and replay prevention, to prevent such man in the middle attacks? 6) there is mention of DNS providing cacheing. I have some concerns that this may not be appropriate for DNS applicability, and there could be security concerns introduced if DNS is used to provide cacheing for this protocol. - Other comments: 1) I found the 1st paragraph of section 4 unparseable. I recommend using multiple sentences here, rather than one long run-on sentence. 2) s/(ie,/(i.e.,/g 3) This document should have **requirements**, and the informative notes feel wishy-washy. Many requirements are not definitive requirements, so it will be hard to tell whether the protocol actually meets the requirements. Some of the informative notes gave a much better description of what is expected, and I think the non-informative-note-text would benefit from being described more fully, and eliminating the informative notes. 4) I think some MUST/SHOULD language is not being used as per RFC2119, and should be tightened. There is also use of lowercase "must" and "should"; is this meant to also be consistent with RFC2119 usage? If not, the "requirements language" section should explain this. 5) section 5.2 bullet#3 says "If the infrastructure doesn't provide caching (ala DNS), the records retrieved MUST provide initiators the ability maintain their own cache." I don't understand how retrieved records can provide this ability to initiators. Either the protocol needs to provide a caching mechanism (possibly ala DNS), or implementations do. 6) There are a number of sentences in this document that do not follow the rules of English grammar. For example, in the 1st paragraph of section 5.3, there is no subject-verb formualtion, only a couple of cluases strung together. The grammar makes it hard to read this document without being forced to go over sentences multiple times to understand the intent. 7) "intuitive" is in the mind of the beholder. I think it is debatable whether p=? is less intuitive than p=unknown. What is needed is a clear and unambiguous syntax about what p=? or p=unknown means. 8) section 5.4 bullet#1 sounds like something to write in the charter, not the protocol requiremnets document. 9) section 5.4 bullet#2 - are there already existing discovery/transport/practices to be backwards compatible with? Or is this saying the future extensions to the future protocol must be backwards compatible with the future protocol? David Harrington dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf --------------020402010403070902010802 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html --------------020402010403070902010802-- From ietf-dkim-bounces@mipassoc.org Tue Jul 17 06:32:55 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAkMR-0003oR-4p for ietf-dkim-archive@lists.ietf.org; Tue, 17 Jul 2007 06:32:55 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAkMN-0000pC-EM for ietf-dkim-archive@lists.ietf.org; Tue, 17 Jul 2007 06:32:55 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6HAV9Xn023332; Tue, 17 Jul 2007 03:31:10 -0700 Received: from winserver.com (listserv.winserver.com [208.247.131.9]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6HAUx2s023296 for ; Tue, 17 Jul 2007 03:31:00 -0700 Received: by winserver.com (Wildcat! SMTP Router v6.2.452.2) for ietf-dkim@mipassoc.org; Tue, 17 Jul 2007 06:31:07 -0400 Received: from hdev1 ([72.144.68.37]) by winserver.com (Wildcat! SMTP v6.2.452.2) with ESMTP id 3006939407; Tue, 17 Jul 2007 06:31:06 -0400 Message-ID: <469C9A50.9070005@santronics.com> Date: Tue, 17 Jul 2007 06:30:40 -0400 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [ietf-dkim] [Fwd: secdir review of draft-ietf-dkim-ssp-requirements-04] References: <469C5982.9000300@cisco.com> In-Reply-To: <469C5982.9000300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: IETF-DKIM X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Eliot, Thanks for the FYI. It reaffirms what my own assessment of the SSP requirements document. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Eliot Lear wrote: > FYI > > ------------------------------------------------------------------------ > > Subject: > secdir review of draft-ietf-dkim-ssp-requirements-04 > From: > "David Harrington" > Date: > Mon, 16 Jul 2007 17:27:41 -0400 > To: > , , "'Sam Hartman'" > , > > To: > , , "'Sam Hartman'" > , > CC: > "'Michael Thomas'" , "'IETF discussion list'" > > > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Security review: > draft-ietf-dkim-ssp-requirements-04 discusses requirements for the > DKIM signing practices protocol. I felt the discussion of security > issues for DKIM signing was very light. The Security Considerations > section was also too light. > > My advice to the security area directors is that, before publication, > this draft should document stronger security requirements for the DKIM > signing protocol. This document should include an enumeration of the > potential threats, as described in BCP 72 (RFC3552), followed by a > discussion of the requirements that must be met by DKIM signing to > mitigate those threats. > > - > a few specific comments related to security issues: > 1) section 5.1 discusses discovery requirements. bullet#1 says the > author is the first party sender of a message. After reading this, I > had the question "author of what?" The preceding text only says there > must be a means of obtaining information. It doesn't discuss any > particular approach to getting the information, so I am not sure what > is being authored. > > 2) section 5.1, bullet #4 says the WG might not be able to reach a > consensus on a solution that completes within a deterministic number > of steps, and if they do not reach consensus, then they MUST document > the relevant security considerations. Even if they DO reach consensus, > they will need to document the security considerations. I'm not sure > how they will document the security considerations of not reaching > consensus. I think there are range of topics mixed into bullet#4, and > they need to be broken out before security for these things can be > considered. > > 3) section 5.3 bullet #2 calls for a concise linkage between the > identity in the From field and the DKIM i= tag. Isn't the concise > linkage that you need here some type of identity authentication? If > not, how do you know the mapping is actually valid? > > 4) security requirement#1 - What must SSP do to prevent such DoS > attacks? what must SSP do to prevent being vulnerable to such DoS > attacks? Note that these are two separate questions with potentially > different mitigation strategies. > > 5) security requirement#2 - what must SSP do to prevent such attacks? > Keeping exchanges small might help, but how about establishing a > secure channel, and using data origin authentication, and message > integrity checking, and replay prevention, to prevent such man in the > middle attacks? > > 6) there is mention of DNS providing cacheing. I have some concerns > that this may not be appropriate for DNS applicability, and there > could be security concerns introduced if DNS is used to provide > cacheing for this protocol. > > - > Other comments: > 1) I found the 1st paragraph of section 4 unparseable. I recommend > using multiple sentences here, rather than one long run-on sentence. > > 2) s/(ie,/(i.e.,/g > > 3) This document should have **requirements**, and the informative > notes feel wishy-washy. Many requirements are not definitive > requirements, so it will be hard to tell whether the protocol actually > meets the requirements. Some of the informative notes gave a much > better description of what is expected, and I think the > non-informative-note-text would benefit from being described more > fully, and eliminating the informative notes. > > 4) I think some MUST/SHOULD language is not being used as per RFC2119, > and should be tightened. There is also use of lowercase "must" and > "should"; is this meant to also be consistent with RFC2119 usage? If > not, the "requirements language" section should explain this. > > 5) section 5.2 bullet#3 says "If the infrastructure doesn't provide > caching (ala DNS), the records retrieved MUST provide initiators the > ability maintain their own cache." I don't understand how retrieved > records can provide this ability to initiators. Either the protocol > needs to provide a caching mechanism (possibly ala DNS), or > implementations do. > > 6) There are a number of sentences in this document that do not follow > the rules of English grammar. For example, in the 1st paragraph of > section 5.3, there is no subject-verb formualtion, only a couple of > cluases strung together. The grammar makes it hard to read this > document without being forced to go over sentences multiple times to > understand the intent. > > 7) "intuitive" is in the mind of the beholder. I think it is debatable > whether p=? is less intuitive than p=unknown. What is needed is a > clear and unambiguous syntax about what p=? or p=unknown means. > > 8) section 5.4 bullet#1 sounds like something to write in the charter, > not the protocol requiremnets document. > > 9) section 5.4 bullet#2 - are there already existing > discovery/transport/practices to be backwards compatible with? Or is > this saying the future extensions to the future protocol must be > backwards compatible with the future protocol? > > David Harrington > dbharrington@comcast.net > ietfdbh@comcast.net > > > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > > ------------------------------------------------------------------------ > > _______________________________________________ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 19 15:00:57 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBbFB-0004IE-E9 for ietf-dkim-archive@lists.ietf.org; Thu, 19 Jul 2007 15:00:57 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBbFA-0007Pt-Dd for ietf-dkim-archive@lists.ietf.org; Thu, 19 Jul 2007 15:00:57 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6JIu5nt026155; Thu, 19 Jul 2007 11:56:19 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6JItxEc026098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 19 Jul 2007 11:55:59 -0700 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id 4D167414CF; Thu, 19 Jul 2007 11:56:06 -0700 (PDT) In-Reply-To: <46998505.7090807@dcrocker.net> References: <4691300D.5000001@dcrocker.net> <46913920.5020200@mtcc.com> <46998505.7090807@dcrocker.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <453160E5-1442-4F4D-90AA-47A7A5BBFF7F@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Choices about Practice vs. Publication Date: Thu, 19 Jul 2007 11:56:06 -0700 To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: DKIM WG X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 On Jul 14, 2007, at 7:23 PM, Dave Crocker wrote: > Michael Thomas wrote: >> Dave Crocker wrote: >>> I think a simple and appropriate model, here, is that the >>> receive-side should be given information that permits it to >>> detect external attacks -- that is, misbehaviors by actors >>> external to the origin-side. > ... >> In which case, the bob and jane @ earthlink problem is really >> earthlink's to deal with. I think that's entirely appropriate; it >> is completely within earthlink's capability to, say, use SMTP AUTH >> to gate users to deal with this attack. > > You might be referring to a different issue, but I think the i= > parameter makes this particular issue moot. Might have been an > interesting discussion about 2 years ago, but not so much now. The i= provides an identity which may omit the local-part of the address on who's behalf the message is signed. DKIM does not ensure this identity is meaningful in regard to the visual content of a message. A key located within an email-address sub-domain represents a third-party signature. In which case, the i= parameter is unable to identify an address within a parent domain that is likely recognized by the recipient. However, the overview draft makes an assumption regarding the utility of sub-domain signatures. In doing so, this creates a new security concern. What utility was envisioned by this suggestion? In the draft-ietf-dkim-overview document, --- 1.3.3. The Selector construct ... Signers do have the need for supporting multiple assessments about their organization, such as to distinguish one type of message from another, or one portion of the organization from another. To permit assessments that are independent, an organization should use different sub-domains in the "d=" parameter, such as "transaction.example.com" versus "newsletter.example.com", or productA.example.com versus productB.example.com. 2.6.1.3. Subdomain Considerations A Domain Name is the basis for making differential quality assessments about a DKIM-signed message. It is reasonable for a single organization to have a variety of very different activities, which warrant a variety of very different assessments. A convenient way to distinguish among such activities is to sign with different domain names. That is, the organization should sign with sub-domain names that are used for different organizational activities. --- RFC4871: 3.5. The DKIM-Signature Header Field ... d= The domain of the signing entity (plain-text; REQUIRED). This is the domain that will be queried for the public key. This domain MUST be the same as or a parent domain of the "i=" tag (the signing identity, as described below), or it MUST meet the requirements for parent domain signing described in Section 3.8. When presented with a signature that does not meet these requirement, verifiers MUST consider the signature invalid. --- Note: Section 3.8 conditionally permits valid signatures for sub- domain email-addresses only when not disabled by a flag within key records. The DKIM overview makes a recommendation that did not receive much list discussion. This appears to be based upon an assumption that sub-domain signatures could be considered authoritative for a parent domain within the realm of "assessments." "Assessments" is a rather nebulous term. Even parent domain signatures represent a risk partially addresses by RFC4871 #3.8. Nothing within DKIM provides a means to limit sub-domain signature "assessments", as such signatures simply are not valid for parent domain email-addresses! Allowing parent domain signatures is problematic from a security and complexity standpoint. Suggesting that sub-domains can be used for "assessment" purposes invites a fair amount of abuse. This means the 'i=' identity is unlikely to be meaningful to the email recipient as well. Was sub-domain signatures considered to be a method to partition domains into differently vetted categories? Was this to isolate sources where replay abuse may be less problematic? There are security issues created by controlling message "assessments" by sub- domains. This type of signature is not itemized within the SSP policy, nor can these types of signatures be explicitly controlled beyond outright prohibition of third-party signatures. Prohibition of third-party signatures thereby prevents this utility. Is this recommendation based upon there being an exception in the definition of "third-party" signatures? A recipient can safely obtain assurances from a sub-domain signature by providing a by-name SSP authorization strategy. A by-name authorization as provided in TPA-SSP can thereby limit the scope of third-party signatures. The difference is rather stark, specifically when, as the overview suggests, there is a need for multiple assessments. http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.html http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-01.txt -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Sun Jul 22 23:33:19 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICoff-0006Ld-FI for ietf-dkim-archive@lists.ietf.org; Sun, 22 Jul 2007 23:33:19 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICofd-0002i9-S7 for ietf-dkim-archive@lists.ietf.org; Sun, 22 Jul 2007 23:33:19 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6N3Vohw029642; Sun, 22 Jul 2007 20:31:57 -0700 Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6N3Vjvv029606 for ; Sun, 22 Jul 2007 20:31:46 -0700 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2007 05:31:49 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAJa9o0aQ/uCKh2dsb2JhbACPWgEBCQon X-IronPort-AV: i="4.16,569,1175464800"; d="scan'208"; a="148702520:sNHT12788130028" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6N3Vm7k023484 for ; Mon, 23 Jul 2007 05:31:48 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6N3Vhkt001051 for ; Mon, 23 Jul 2007 03:31:48 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 05:31:43 +0200 Received: from fenton-mac.local ([10.61.64.103]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 05:31:42 +0200 Message-ID: <46A420BF.1050107@cisco.com> Date: Sun, 22 Jul 2007 20:30:07 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: IETF DKIM WG X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2007 03:31:42.0680 (UTC) FILETIME=[FCEE6580:01C7CCD9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8670; t=1185161508; x=1186025508; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Review=20of=20draft-ietf-dkim-overview-05 |Sender:=20; bh=B2/DQdm8fcasoHt6sbPBF7Rn8W9J5ybZiCaeAk6Sypo=; b=F4Sv1UVHYqKPK4VDfywt6DdxS0WWIS11Pk7VokmoCQ4kOAXIcyufuGCibn3c2iJuj3IpqtT5 f5FPSkGUD1mmTrHUzLNiYKPAocUebqsysTM4pIxswZtb1T4UrFb0ewCp; Authentication-Results: ams-dkim-1; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Songbird: Clean, Clean Subject: [ietf-dkim] Review of draft-ietf-dkim-overview-05 X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Below are some comments on dkim-overview-05. I'll start out with some general comments and then go through section by section. I'll try to avoid grammatical nits at this point, although sometimes I just can't help myself. General: The document seems to be inconsistent as to whether it's just being descriptive of DKIM and its environment or whether it's a normative document. The language used seems to be all over the place between descriptive, "the verifier obtains the domain name from the DKIM header field," non-normative "should" and normative "SHOULD." There's some inconsistency as to whether SSP is included in this overview, and where it is, it makes some assumptions about SSP that haven't been decided yet. There is little guidance about the use of multiple signatures in a message. In particular, an invalid signature shouldn't cause the message to be treated as unsigned: there could be other valid signatures. Top-level structure of the document needs serious work. There are a lot of subsections that don't fit within the section they're in. The introductory material seems to go on forever. The background on the email administrative structure should be limited to the minimum that is needed to set the foundation for the rest of the document. Specifics: 1.1 paragraph 1: Use present, not future, tense. 1.1.1 paragraph 3 s/An attack is made/Suppose an attack is made/ "leverage" implies amplification: need a better word. s/DKIM-based accreditation/domain-based accreditation/ (and please define accreditation somewhere). s/enforce a basic separation/differentiate/ 1.1.1 paragraph 4 s/It can also/They can also/ Example of "independent service"? s/the basis/a basis/ 1.1.1 paragraph 5 s/not signed by email/not signed by DKIM/ Should SSP be mentioned, since it affects how unsigned mail might be handled? 1.1.2 paragraph 1 s/therefore trusted to be accurate/therefore assumed to be accurate/ 1.1.2 paragraph 5 s/semantic implication of the assertion/semantic assertion/ 1.1.2 paragraph 6 don't understand what is meant by "technical aspect" 1.1.3.1 Under ADMD Examples, why is an ISP an ADMD, unless it is also a Mail Service Provider? 1.1.4 paragraph 2 delete 1.2 I thought 1.1.1 was all about the goals of DKIM? 1.2.1 Do we want to make any comparisons with SPF or SenderID, even though they are Experimental? In particular, they also work at the domain level. 1.2.1 paragraph 2 s/sign with any domain name/sign with any domain name for which they have authority/ s/DKIM needs to support/DKIM supports/ This paragraph in particular sounds like a list of requirements (or deficiencies) for DKIM, rather than what it does, e.g., "DKIM must support this mode of activity" s/not visible/not typically visible/ 1.2.1 paragraph 3 Ability to send a message without signing is also a factor in providing anonymity. s/does not threaten the anonymity of the user/may not threaten the anonymity/ (a signature from my personal domain would definitely threaten my anonymity!) 1.2.2 paragraph 2 Need to reword in terms of invalid signatures being ignored, not treating the message as a whole as (necessarily) unsigned. The treatment of failed signatures as not present does not derive from transparency, but rather from the following consideration: Message signatures MAY break in transit, so treating a message with a broken signature any worse than an unsigned message would tend to discourage signing. 1.2.2 paragraph 4 Delete "accreditation" since that is done on behalf of the sender, and this is talking about a list maintained by the receiver. 1.3 SSP should be referenced here. 1.3.1 Don't understand first sentence; perhaps s/associates a domain name with an address/chooses a sending identity/ 1.3.1 paragraph 3: Does this belong in 1.3.3? The service restriction isn't nearly as interesting as the key record's restriction of signing algorithms and perhaps the user-part of the signing address. 1.3.3 first sentence: A signature really associated with a signing address, specified in the i= tag, although the entity doing the signing usually does so for all addresses in the domain. d= is really the place to look for the key, and may be the same as or sometimes a parent of the domain-part of i=. 1.3.3 paragraph 4: I have some trouble with the "should use different sub-domains" (assuming it's trying to be normative). This is, in effect, recommending changes in the way organizations address their email, which I thought we were trying to avoid. It's also not clear to me whether reputation services will key off d= or i=; using i= probably makes it easier to make up subdomain names in order to avoid negative reputation, but it's fairly easy with d= as well (just requires more key records). 1.4: Figure 4 doesn't address multiple signatures. 1.4 paragraph 3: s/Unsigned messages/Messages lacking a valid signature corresponding to the <2822.From> address/ 1.4 paragraph 4: "are treated": is this normative? 2.1.1 There isn't much that's unique about DKIM in terms of crypto coding considerations. Isn't there something we can reference? In paragraph 4, why would timing attacks be limited to dual-core and multiprocessor configurations? 2.1.2 paragraph 4: Why would certificate registration make any difference at all? 2.1.2 Should there be any guidance on delegation of keys? Should there be a section 2.1.3 giving guidance to verifiers? 2.2 paragraph 2: To whom (the submitter or the email administrator) is the "operator alert" issued? I'm mixed about the utility of such alerts, because the vast majority of non-compliant non-signers will submit through a completely different path that doesn't do any checking. If this is normative, I'd make it a MAY. 2.3 paragraph 2: s/about the message/about the message or the signing domain/ s/a spammer or other malefactor/an attacker/ 2.3 paragraph 4: s/scheme/verifier/ s/reputation data/reputation data (including locally-maintained whitelists)/ 2.5.2.1 talks about what the verifier does, but it's under section 2.5.2 "Signing". 2.5.3.1 paragraph 2: How does the first sentence relate to SSP? 2.5.3.3 paragraph 2: advocate stripping only those Authentication-Results header fields that purport to be from the ADMD doing the stripping. Otherwise this may break DKIM signatures that sign Authentication-Results header fields as described under "intermediaries" in section 2.2. 2.5.5.1 talks about advertising the algorithms that are both being used dueing a transition period, but 2.5.5.2 does not reference that advertisement. Why is it required? 2.5.6.1 paragraph 2: s/principle/principal/ 2.5.6.1 doesn't talk about whether either signature signs the other. IMO the signatures should be independent, which means that the DKIM signature must precede the DK signature. 2.5.6.2. paragraph 2: what is there to see in the section on Signing? Are there any SSP issues to consider? 2.6 first bullet: s/files/records/ 2.6.1: First paragraph might also discuss the option of putting the _domainkey subdomain in a separate zone which is maintained directly by the email staff. Second paragraph s/WILL and// 2.6.1.1: bullet 3, what kind of "exposure" do you mean? 2.6.1.3: it was a goal (of IIM, anyway) not to require domains to change their addressing practices, such as this describes. Maybe we didn't achieve that, but the ability for an attacker using his/her own domain to create a new subdomain and get a fresh reputation brings the reputation-silo-via-subdomain issue into question. I thought we were considering ways of maintaining reputation as out-of-scope for the WG? In other words, I wouldn't expect that reputation providers will necessarily work this way. 2.6.1.4: This uses the term "third-party" in a different meaning than its use in SSP. We should resolve this. 2.6.3: Why is the section on Mailing list manager developers" under "On-going operations"? There should be some guidance on what signing address should be used by mailing lists: is it the sender, list-ID, etc.? owner-list@example.com, list@example.com, or list-bounces@example.com? 2.7.1: "...can be presumed to be spurious". Not so; messages could originate from the domain, be sent to a mailing list that breaks the signature, and back to the same or other users in the originating domain. 2.7.2.1: I don't understand what these are. Accreditations? Missing Security Considerations and IANA Considerations sections. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Jul 23 11:01:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzPM-0004tl-D7 for ietf-dkim-archive@lists.ietf.org; Mon, 23 Jul 2007 11:01:12 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzPK-00009e-Rf for ietf-dkim-archive@lists.ietf.org; Mon, 23 Jul 2007 11:01:12 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6NExTk9031119; Mon, 23 Jul 2007 07:59:35 -0700 Received: from [130.129.82.242] ([130.129.82.242]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6NEx5mD030953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jul 2007 07:59:07 -0700 Message-ID: <46A4C248.6040603@dcrocker.net> Date: Mon, 23 Jul 2007 09:59:20 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [ietf-dkim] ISSUE: dkim-overview -- normative statements References: <46991C15.7000405@dcrocker.net> <46994301.3030303@cisco.com> <46994CE3.3010601@dcrocker.net> <4699D27C.5080708@cisco.com> In-Reply-To: <4699D27C.5080708@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Eliot, Eliot Lear wrote: > As a general rule I believe you are better off with fewer documents with > normative text than more. As a general rule, I believe the number of documents should strike a useful balance between flexibility for later enhancement and ease of cross-reference while reading the specification. These are competing constraints, since the former argues for more documents and the latter argues for fewer. We have seen problems with too few documents and others with too many. Both problems tend to be serious in the long run. Again, this is why I suggested that this thread worry a bit less about generic rules -- bu note that "a bit less" does not mean "not at all" -- than about the particulars of the current situation. For example: 1. -base and -ssp exist. So does -overview. What we do not officially have is a document that describes the integrated service. -base and -ssp do not seek that role, so this is hardly an matter of their being "deficient". 2. -overview has evolved. As you and Jim Fenton have done so diligently, other folk should take a careful look at it and describe what areas of discussion it has that they believe should be eliminated or moved elsewhere. (If the latter, then where? If they think it should be eliminated, then why?) 3. -overview must not be redundant with any other normative text. Every time we've had two normative documents make normative statements about the same thing, we've hadlong-term problems. So I suspect no one will argue with this. Where the current -overview draft does appear to be redundant, the text should either be eliminated or modified to sound purely pedagogical, possibly with a reference to the proper, external normative text. Such redundancies are not uncommon when developing tutorial material, since that's sort of its purpose. The problem, in these cases, is with the nature of the language, not the topic. > There is a lot of text around mailing lists > that comes dangerously close to text in the SSP draft (see -overview > Section 2.5, and -ssp, Section 5.1). Auditing, to catch possible discrepancies and redundancies, is extremely helpful. > The last thing we want are two > documents that mandate behavior in the same components in what could end > up being subtly different ways. Completely agree. > It may be useful to have a BCP or an overview, but the scope of that > document must be made clear, and should not overlap with standards > specifications. The use of normative language in the draft today is > IMHO inappropriate even for a BCP, and in some cases is overly broad. In Section 1.1, par 3, the opening sentence is: "This document provides a description of DKIM's architecture, functionality, deployment and use. " That's rather terse, but I'm not understanding what additional statements you would like to see. Is there more than a clear disclaimer that any statements that appear to conflict with DKIM specification documents are resolved by taking the normative portions of the specification documents as definitive? > Here are two examples: > > * In section 2.1 you talk about memory models and keeping private > keys private. I think that states the obvious, while at the same > time going way down the implementation path. If you're going to > state the obvious, do so once and not at only some of numerous > opportunities for a key to be exposed. Furthermore, this text > goes into implementation design. That's not BCP territory, IMHO. > * In Section 2.2 you talk about requiring secure zone updates > without really defining what you mean. Are you, for instance, > talking about DNS registrars needing to use SSL? Is a login > password good enough or is that not strong enough? Is DDNS useful > in this context? If so, how? If not why not? (I'd argue the > latter, but there's no argument in there at all right now.) Well, your friendly authors certainly had some discussion about the scope of this section. My sense of the motivation for the section is that security coding and operations issues are not well-ingrained in the industry and that, therefore, some basic tutorial about generic issues, would be helpful. (This, of course, does not mean that the current text there -- or anywhere else in the document -- would not benefit from revision.) > Given these issues, how would you want to proceed? > > Finally, because it's clear that a fair amount more work is needed on > this document, and as SSP is progressing, I think it would be prudent to > be mindful of SSP, and to reconsider gating this document to SSP, > assuming we keep moving forward on the latter. The industry needs -overview today. Not tomorrow. Some of us attended a Federal Trade Commission anti-spam workshop where we heard a senior FTC staffer state that the only way he could familiarize himself with DKIM was to read -base. This is such an unreasonable demand to place on him that it's not his fault that he viewed DKIM as too complicated and risky... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Jul 23 15:54:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3yl-0007JA-08 for ietf-dkim-archive@lists.ietf.org; Mon, 23 Jul 2007 15:54:03 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID3yj-0001ag-MH for ietf-dkim-archive@lists.ietf.org; Mon, 23 Jul 2007 15:54:02 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6NJqn8A005776; Mon, 23 Jul 2007 12:52:55 -0700 Received: from c3po.altn.com (c3po.altn.com [65.240.66.134]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6NJqhDY005730 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jul 2007 12:52:43 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=altn.com; s=c3po; l=3525; t=1185220373; x=1185825173; q=dns/txt; h=DomainKey-Signature: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding:VBR-Info; bh=fKyRPox7kCgg DB1I1h2I+zILmK/M9XaOw4W0H5VHLTc=; b=IeB8Of7BPVlPia4lA2JWttceOQBG EESIuml52z+LtHOBPb9LYfE1J7VvcYa4oO18na3IEP6ZDwTsVU4xUJX3FXo8+5/S 5d8BUguc0LCZzpcui/maypQehRKWX1rECeOAr1f9tRAZdiykrqgmyo+A2AeFehi1 RBDaUJJVF1qKnxc= DomainKey-Signature: a=rsa-sha1; s=c3po; d=altn.com; c=nofws; q=dns; h=message-id:from; b=AlKvq2oI03Bwf1cOvbOyRqu4slYwEbBvb7Y0M75yaz9DfoJQ6USFCnZxNLP8 ONHSe12TpfocpaZVG7QijC4MiX076qmwx8+gYG+Wa3ywHJHBEKcCP40fR MNSTixwOw7vSFUcPe7y+aG/5apmfpfZ7M+TSRVtb4LVatZXL3AbDGY=; Received: from arvel-hathcocks-computer.local by altn.com (MDaemon PRO v9.6.2f) with ESMTP id md50002281182.msg for ; Mon, 23 Jul 2007 14:52:52 -0500 Message-ID: <46A5070E.9020101@altn.com> Date: Mon, 23 Jul 2007 14:52:46 -0500 From: Arvel Hathcock User-Agent: Thunderbird 2.0.0.4 (Macintosh/20070604) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit VBR-Info: md=altn.com; mc=all; mv=vbr.emailcertification.org; X-Authenticated-Sender: Arvel.Hathcock@altn.com X-HashCash: 1:21:070723:md50002281182::rpnmeVumdZtTyeEp:00004J+m X-Spam-Processed: c3po.altn.com, Mon, 23 Jul 2007 14:52:52 -0500 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 67.97.210.2 X-Return-Path: prvs=1724241813=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: ietf-dkim@mipassoc.org X-MDAV-Processed: c3po.altn.com, Mon, 23 Jul 2007 14:52:53 -0500 X-Songbird: Clean, Clean Subject: [ietf-dkim] SSP draft suggestions X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Just a few small suggestions: 1) In several places the language "SHOULD be considered non-Suspicious" is used. This seems an awkward way to say it. Since the term "Suspicious" is defined in section 2.8 "SHOULD NOT be considered Suspicious" might be a better way? Also "MUST be considered non-Suspicious" -> "MUST NOT be considered Suspicious"? 2) Section 3 bullet point 3 - "and SHOULD have a Valid Signature from this domain" -> "and SHOULD have a valid Originator Signature" 3) "not to be legitimate" -> "to be illegitimate" 4) ", and any verifiable signature is present from some signer other than the Originator Address in the message" -> "and the message contains a Verifier Acceptable Third-Party Signature" 5) "SHOULD NOT be considered to be Suspicious" -> "SHOULD NOT be considered Suspicious" 6) Section 4.1 - perhaps this is a better way of stating the second sentence in the NON-NORMATIVE DISCUSSION paragraph: "Many DNS server and resolver implementations are incapable of quickly and easily supporting new resource record types. For this reason, support of TXT records is required whether a new RR type is defined or not." 7) Section 4.1 states that syntactically incorrect SSP records should be considered as NODATA. This is different from the 4871 approach of simply ignoring unknown tag/value combinations. This also precludes the ability to extend an existing SSP record with some future new tag (should that need ever arise). Was this intended? It seems to contradict what's stated later in 4.3 that unknown tags are to be ignored. 8) "whcih" -> "which" 9) "Originating Domain" is used as if it was one of the previously defined terms but it isn't. 10) "and its all of its" -> "and all of its" 11) Personally, I like the suggestion someone else made of changing "unknown" to "?" but this isn't particularly important really. 12) Section 4.4 - "including any where the Alleged Signer is" -> did you mean "including anywhere the Alleged Signer or" 13) Algorithm 2 - "to the domain part of the Originator Address" - it seems like you'd want to define "Originator Domain" in the definitions section and use that in a few places. 14) Algorithm 2 - "with one or more answer which is a syntactically-valid SSP response" -> "with one or more syntactically valid SSP responses" 15) Algorithm 3 has me a little worried. It would prevent the use of domains unless they explicitly exist in DNS. So, if I wanted to send a message out from message@sms.altn.com I would have to make sure and create a DNS A record or something for sms.altn.com first right? (sorry, my knowledge of DNS is not so good) 16) Algorithm 4 - "of the domain part of the domain part" -> "of the domain part" this is another case where defining Originator Domain in advance might be helpful. 17) Algorithm 4 - "is a top-level domain" how can that be determined in practice? I don't think it can can it? If not, we're giving algorithmic instruction here that is impossible to implement. 18) Algorithm 5 - unless we can figure out how to stop queries at top-level domains, Algorithm 5 will send lots of queries to the root servers right (.co.uk for example)? 19) Algorithm 8 - "and one or more Valid Signatures are present" -> Valid Signatures doesn't say enough here. In this case a valid Originator Signature or a valid Verifier Acceptable Third-Party Signature" is what you want. Arvel _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Wed Jul 25 10:57:54 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDiJG-00055c-46 for ietf-dkim-archive@lists.ietf.org; Wed, 25 Jul 2007 10:57:54 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDiJF-0000l8-Fu for ietf-dkim-archive@lists.ietf.org; Wed, 25 Jul 2007 10:57:54 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6PEsP0I007457; Wed, 25 Jul 2007 07:54:39 -0700 Received: from c3po.altn.com (c3po.altn.com [65.240.66.134]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6PEsGQF007392 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 25 Jul 2007 07:54:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=altn.com; s=c3po; l=1489; t=1185375262; x=1185980062; q=dns/txt; h=DomainKey-Signature: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Content-Transfer-Encoding:VBR-Info; bh=+JV9sn/aUC1i Z37r+d+gW73S/dRNWD99oLcn6YcEjLE=; b=mxwEczZA1SutC8ROa52wdYN5CDdg 1F7qQwTbD3tuw/6O1QmZGp2jb/JWdls3xwmzu4vnh6G4TmXwlZmlWz4xwxQBu887 brE3otgsMn/jzWXHRJAe4eCkGrhEUb/nPQSoTYVLnoVGUqPoZyRczgeCDVXA8U5f LCSuBk6QgeRef5A= DomainKey-Signature: a=rsa-sha1; s=c3po; d=altn.com; c=nofws; q=dns; h=message-id:from; b=IKIlTV7jPsMAfMfTzwFersO8x50ZE06Os0AW6MgrOa9A+lU3d24Wv8KBd5O9 3Sc1sbCWcdRapsa8Vrz8UJFZby5AAQFLSnWjXvL2W2gokD/f3dY5zey+A ID1HSudgXYA9zAI73xmxMkiGEPOQg2LGWMIQhJqqd8UCLyw68BjWpc=; Received: from arvel-hathcocks-computer.local by altn.com (MDaemon PRO v9.6.2rc1) with ESMTP id md50002285325.msg for ; Wed, 25 Jul 2007 09:54:20 -0500 Message-ID: <46A76413.6060206@altn.com> Date: Wed, 25 Jul 2007 09:54:11 -0500 From: Arvel Hathcock User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit VBR-Info: md=altn.com; mc=all; mv=vbr.emailcertification.org; X-Authenticated-Sender: Arvel.Hathcock@altn.com X-HashCash: 1:21:070725:md50002285325::0Z6xUw0uh/gOMuej:00005thw X-Spam-Processed: c3po.altn.com, Wed, 25 Jul 2007 09:54:20 -0500 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 67.97.210.2 X-Return-Path: prvs=172687399b=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: ietf-dkim@mipassoc.org X-MDAV-Processed: c3po.altn.com, Wed, 25 Jul 2007 09:54:22 -0500 X-Songbird: Clean, Clean Subject: [ietf-dkim] Thoughts on latest SSP draft X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi all! I believe that the algorithm specified in the latest SSP draft (section 4.4) is the best compromise possible and that it will cover the largest percentage of use cases. However, I agree it's not perfect. Algorithm steps #4 and #5 are the problem as there is no definitive list of TLDs available and yet these steps call for the use of such. As an implementor I'm worried about how I can comply with this part of the algorithm. These steps suggest the use of a locally maintained or implementation specific TLD list. But such lists would necessarily differ from one deployment or implementation to another leading to inconsistent application of SSP in the wild. This worries me greatly. I'd like us to at least consider the possibility of removing the steps associated with querying the immediate parent of the domain in question (steps #4 and #5). Admittedly, this causes more administrative hassles for certain classes of senders but no solution to this question will be perfect in all cases. I keep coming back to this: some of the brightest people I've ever meet are members of this WG yet we are still grappling with this issue. I think this points to the fact that maybe we can't solve this one and that we should accept that and move forward with an even simpler algorithm (by removing these two steps). Anyway, I bow to the collective wisdom here of course but I'm hoping we can at least discuss this some. Arvel _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Wed Jul 25 15:13:12 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDmIK-0007di-0s for ietf-dkim-archive@lists.ietf.org; Wed, 25 Jul 2007 15:13:12 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDmII-0002Bq-GQ for ietf-dkim-archive@lists.ietf.org; Wed, 25 Jul 2007 15:13:12 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6PJC5n0011075; Wed, 25 Jul 2007 12:12:10 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6PJBxGU011012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Jul 2007 12:12:00 -0700 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id 9749C41422; Wed, 25 Jul 2007 12:12:04 -0700 (PDT) In-Reply-To: <46A76413.6060206@altn.com> References: <46A76413.6060206@altn.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77442E31-D9F3-4961-B54B-C0296B9E536A@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] Thoughts on latest SSP draft Date: Wed, 25 Jul 2007 12:12:04 -0700 To: Arvel Hathcock X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a On Jul 25, 2007, at 7:54 AM, Arvel Hathcock wrote: > Hi all! > > I believe that the algorithm specified in the latest SSP draft > (section 4.4) is the best compromise possible and that it will > cover the largest percentage of use cases. However, I agree it's > not perfect. Algorithm steps #4 and #5 are the problem as there is > no definitive list of TLDs available and yet these steps call for > the use of such. As an implementor I'm worried about how I can > comply with this part of the algorithm. These steps suggest the > use of a locally maintained or implementation specific TLD list. > But such lists would necessarily differ from one deployment or > implementation to another leading to inconsistent application of > SSP in the wild. This worries me greatly. > > I'd like us to at least consider the possibility of removing the > steps associated with querying the immediate parent of the domain > in question (steps #4 and #5). Admittedly, this causes more > administrative hassles for certain classes of senders but no > solution to this question will be perfect in all cases. > > I keep coming back to this: some of the brightest people I've ever > meet are members of this WG yet we are still grappling with this > issue. I think this points to the fact that maybe we can't solve > this one and that we should accept that and move forward with an > even simpler algorithm (by removing these two steps). > > Anyway, I bow to the collective wisdom here of course but I'm > hoping we can at least discuss this some. No organization is able to impose changes to SMTP without the general consent of those creating and using the protocol. Nevertheless, to deal with an emergence of IPv6, cryptographic assurances offered by DKIM should prove helpful provided: 1) Common use of multiple signatures is avoided. 2) Per user signatures is avoided. 3) DKIM has an explicit single transaction means to associate SMTP clients with signing domains. 4) DKIM has an explicit single transaction means to associate originating email-address domains with signing domains. (A common mechanism can deal with #3 and #4 and also deal with multiple originating domains.) 5) Email acceptance is predicated upon the originating email-address domain publishing an MX record or A record. At this point in time, it should be rather rare for incoming SMTP servers to depended upon a AAAA record for locating their servers. The DKIM WG should push to have A or AAAA record discovery deprecated. Deprecating address record discovery techniques will eventually simplify where policy needs to be published. At some point in the future, not publishing an MX record for the originating domain might cause a message to be rejected. Either publishing policy at every A or AAAA record is required, or domain transversal (even limited transversal) would be otherwise required. Even limited domain transversal should be avoided. Points #3 and #4 can be fulfilled by placing a hash label below the _ssp._domainkey record of the domain being associated. See: http://tools.ietf.org/wg/dkim/draft-otis-dkim-tpa-ssp-01.txt A: Query for either MX or A or perhaps ANY record at the originating domain in question. B: When no MX or A is discovered, the message is suspect. C: When signed by a third-party domain, query for a ._ssp._domainkey at the originating domain. D: When the hashed SSP record is not found, the signing domain is not authorized. E: When not authorized or not signed, query for the _ssp._domainkey record. F: When no (non-hashed) SSP record is found, there is no policy for the domain. G: When there is a policy for the domain, and it is strict but the message is not signed by either an authorized or first-party domain, the message is suspect. The use of explicit authorization is vital: a) to handle possible replay abuse b) to handle possible compromised keys c) to avoid administrative complexities -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 26 02:59:05 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDxJR-0002eC-BD for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 02:59:05 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDxJP-0005cU-NF for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 02:59:05 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6Q6vSic014541; Wed, 25 Jul 2007 23:57:36 -0700 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6Q6vBMo014492 for ; Wed, 25 Jul 2007 23:57:11 -0700 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 25 Jul 2007 23:57:19 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAF/ip0arR7MV/2dsb2JhbABC X-IronPort-AV: i="4.16,583,1175497200"; d="scan'208"; a="188847641:sNHT30584196" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6Q6vJDP031505; Wed, 25 Jul 2007 23:57:19 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l6Q6vF6C029415; Thu, 26 Jul 2007 06:57:19 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 23:57:14 -0700 Received: from fenton-mac.cisco.com ([10.32.251.9]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Jul 2007 23:57:14 -0700 Message-ID: <46A80AB7.3090109@cisco.com> Date: Wed, 25 Jul 2007 19:45:11 -0700 From: Jim Fenton User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: Arvel Hathcock Subject: Re: [ietf-dkim] SSP draft suggestions References: <46A5070E.9020101@altn.com> In-Reply-To: <46A5070E.9020101@altn.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2007 06:57:14.0600 (UTC) FILETIME=[32914E80:01C7CF52] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5228; t=1185433039; x=1186297039; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fenton@cisco.com; z=From:=20Jim=20Fenton=20 |Subject:=20Re=3A=20[ietf-dkim]=20SSP=20draft=20suggestions |Sender:=20; bh=lMNKLU7lp6Oz1VL8FAR9AonPmG02jpdNDViukX8xpK8=; b=PsvvQhEgnzIWkai5bUn8S+x5zlA/AyyfxhmRoaw4WZErHWGscG/uQ1DVDOWE3bwrZXtTZuWj /ffnit/Mzzgxvb2HuEwc4WjeTK96jR4ox/3kJPbaG84zRySJGTwKq2e2Cm4a4I4vXlaVcgeg1a IpCA+CMOYFWaQeSfiN3sFh0E8=; Authentication-Results: sj-dkim-1; header.From=fenton@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Arvel, Thank you. Eric Allman and I went over your suggestions while we were marking up the SSP draft, and they help a lot. Most of them we're just going to incorporate, so I won't comment on those. Here are our comments on the rest: Arvel Hathcock wrote: > Just a few small suggestions: > > 1) In several places the language "SHOULD be considered > non-Suspicious" is used. This seems an awkward way to say it. Since > the term "Suspicious" is defined in section 2.8 "SHOULD NOT be > considered Suspicious" might be a better way? Also "MUST be > considered non-Suspicious" -> "MUST NOT be considered Suspicious"? We were a little mixed on this. Agree that non-suspicious is probably not a word; it should be "not suspicious". But considering something to be not suspicious is not quite the same thing as not considering something to be suspicious. Even though SSP only produces one of two results, it seems clearer to say that the answer is "not suspicious" than to say that the answer isn't "suspicious". We're doing some wordsmithing on this, including being more consistent on the use of SHOULD and MUST. > > 3) "not to be legitimate" -> "to be illegitimate" The whole use of the word "legitimate" is being removed; it creates confusion about legitimate vs. not suspicious and so forth. So this will be a moot point. > > 4) ", and any verifiable signature is present from some signer other > than the Originator Address in the message" -> "and the message > contains a Verifier Acceptable Third-Party Signature" I like your wording, although this part of the text will be removed when we collapse the text in removing the use of "legitimate". > > > 7) Section 4.1 states that syntactically incorrect SSP records should > be considered as NODATA. This is different from the 4871 approach of > simply ignoring unknown tag/value combinations. This also precludes > the ability to extend an existing SSP record with some future new tag > (should that need ever arise). Was this intended? It seems to > contradict what's stated later in 4.3 that unknown tags are to be > ignored. What this points out is that there isn't actually a formal definition of the record syntax. We need some ABNF for this, and will consider the need for future new tags. > > 11) Personally, I like the suggestion someone else made of changing > "unknown" to "?" but this isn't particularly important really. Eric and I like "unknown" because it's less cryptic and there isn't any reason to save a few characters here. If there's consensus to the contrary, we'll of course change it. > > 12) Section 4.4 - "including any where the Alleged Signer is" -> did > you mean "including anywhere the Alleged Signer or" This sentence will go away. > > > 13) Algorithm 2 - "to the domain part of the Originator Address" - it > seems like you'd want to define "Originator Domain" in the definitions > section and use that in a few places. Yes; thanks for pointing out the repetition. > > 14) Algorithm 2 - "with one or more answer which is a > syntactically-valid SSP response" -> "with one or more syntactically > valid SSP responses" Right. This points out that we need to think about what happens if we get more than one SSP response. Any opinions? > > 15) Algorithm 3 has me a little worried. It would prevent the use of > domains unless they explicitly exist in DNS. So, if I wanted to send > a message out from message@sms.altn.com I would have to make sure and > create a DNS A record or something for sms.altn.com first right? > (sorry, my knowledge of DNS is not so good) You should probably have an MX record anyway for sms.altn.com, especially if that's also the envelope-from address (so it can receive bounces). It doesn't need to be an A record; any record type will do. > 17) Algorithm 4 - "is a top-level domain" how can that be determined > in practice? I don't think it can can it? If not, we're giving > algorithmic instruction here that is impossible to implement. A top-level domain is one that has exactly one component, e.g., "com", "org", "uk", or "tv". We also talk about suffixes, which would probably include "co.uk", "k12.ca.us", and "edu.au". We mandate not querying the top-level domains, since they can be algorithmically determined and we really don't want to unnecessarily load the TLD servers. Not querying suffixes is optional, as the definition for what a "suffix" is, because there is no formal definition and this is really an optimization. > > 18) Algorithm 5 - unless we can figure out how to stop queries at > top-level domains, Algorithm 5 will send lots of queries to the root > servers right (.co.uk for example)? .co.uk isn't a root server, it's a suffix. The root servers are the places you query to find the name servers for ".com", ".us", ".hr", and so forth. It may send quite a number of queries to the .co.uk name servers, which is why you may want to have it in your suffix list, but even if it's not, the number of queries should be limited by the minimum TTL of the zone it's in (the negative caching time). Again, thanks for your comments! -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 26 12:23:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE67G-0001HE-Ol for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 12:23:06 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE67F-000300-9E for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 12:23:06 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QGLBu9018937; Thu, 26 Jul 2007 09:21:19 -0700 Received: from c3po.altn.com (c3po.altn.com [65.240.66.134]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QGL4Vf018878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 26 Jul 2007 09:21:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=altn.com; s=c3po; l=709; t=1185466872; x=1186071672; q=dns/txt; h=DomainKey-Signature: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding: VBR-Info; bh=aQZ1tF8NKRP8/51mMUHRN6b5Pvtqs69nuUSqKjuL0S8=; b=Ch/ 8KMDRLAYb9R00NHld5gKVOAgdEdwtnq/IMCBCmcwgGBC/87j+LvcEqdXoA7Jmy7V qYeogRIUxE2eRCysYgfQLxTIgYNXghCIPczqD5ZWu71A5jtm/xLzW4qOiWL0Iu/N oXBKZIlvEn/VFtLAha6DiYJS+WHKLyrgE8XIfNbM= DomainKey-Signature: a=rsa-sha1; s=c3po; d=altn.com; c=nofws; q=dns; h=message-id:from; b=Shi5PfCJ5njx5hH2TacWmMnYQBcx9P5UaBFL358sDzORkvIl8LL5g7O7UCAO wu2NHVTM7+vRZYZJ3Uai7ZBtpupksRMzYyzEQ3qJeo/NHLYFxYX5/p6/D tEsDyA3wA9kTzhoGzE1y7v8Jdl5sGJLcAu+qGvq32RDocZkgQ7uCts=; Received: from [10.10.50.200] by altn.com (MDaemon PRO v9.6.2rc1) with ESMTP id md50002288598.msg for ; Thu, 26 Jul 2007 11:21:10 -0500 Message-ID: <46A8C9F1.9020909@altn.com> Date: Thu, 26 Jul 2007 11:21:05 -0500 From: Arvel Hathcock User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] SSP draft suggestions References: <46A5070E.9020101@altn.com> <46A80AB7.3090109@cisco.com> In-Reply-To: <46A80AB7.3090109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit VBR-Info: md=altn.com; mc=all; mv=vbr.emailcertification.org; X-Authenticated-Sender: Arvel.Hathcock@altn.com X-HashCash: 1:21:070726:md50002288598::xw4Op06it5juAI2n:0000JyFW X-Spam-Processed: c3po.altn.com, Thu, 26 Jul 2007 11:21:10 -0500 (not processed: message from trusted or authenticated source) X-Return-Path: prvs=1727b21795=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: ietf-dkim@mipassoc.org X-MDAV-Processed: c3po.altn.com, Thu, 26 Jul 2007 11:21:12 -0500 X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > A top-level domain is one that has exactly one component, e.g., "com", > "org", "uk", or "tv". We also talk about suffixes, which would > probably include "co.uk", "k12.ca.us", and "edu.au". We mandate not > querying the top-level domains, since they can be algorithmically > determined and we really don't want to unnecessarily load the TLD > servers. Thanks much for clearing this up for me. I'm obviously not a DNS expert. Now that I understand better I see I was wrong and it will be possible to algorithmically avoid querying the TLDs. So, my concerns surrounding #4 and #5 were based on a misunderstanding on my part which is now cleared up. Thanks again! -- Arvel _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 26 13:18:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE6zA-0000GU-G4 for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 13:18:48 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE6z9-0004Zk-6O for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 13:18:48 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QHHtCM031424; Thu, 26 Jul 2007 10:17:56 -0700 Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QHHnVB031370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 10:17:49 -0700 Received: (qmail 16349 invoked by uid 0); 26 Jul 2007 17:10:20 -0000 Received: by simscan 1.2.0 ppid: 16340, pid: 16344, t: 0.9134s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=6.2 tests=BAYES_99,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO ?67.97.210.184?) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 26 Jul 2007 17:10:19 -0000 Message-ID: <46A8D7BF.4050306@cs.tcd.ie> Date: Thu, 26 Jul 2007 18:19:59 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Jim Fenton Subject: Re: [ietf-dkim] SSP draft suggestions References: <46A5070E.9020101@altn.com> <46A80AB7.3090109@cisco.com> In-Reply-To: <46A80AB7.3090109@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Jim Fenton wrote: > Yes; thanks for pointing out the repetition. >> 14) Algorithm 2 - "with one or more answer which is a >> syntactically-valid SSP response" -> "with one or more syntactically >> valid SSP responses" > > Right. This points out that we need to think about what happens if we > get more than one SSP response. Any opinions? Good question. Would simply using the most restrictive be an option? (Implies a partial order for all SSP statements though, which may not be true in general.) S. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 26 13:20:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE71A-0002yc-JJ for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 13:20:52 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE71A-0004bj-2T for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 13:20:52 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QHJH0S031738; Thu, 26 Jul 2007 10:19:17 -0700 Received: from hiltonsmtp.worldspice.net (hiltonsmtp.worldspice.net [216.37.94.58]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QHJ6b3031674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 10:19:06 -0700 Received: (qmail 16587 invoked by uid 0); 26 Jul 2007 17:11:33 -0000 Received: by simscan 1.2.0 ppid: 16581, pid: 16582, t: 0.8718s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: ** X-Spam-Status: No, score=2.1 required=6.2 tests=BAYES_80,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO ?67.97.210.184?) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 26 Jul 2007 17:11:32 -0000 Message-ID: <46A8D808.4090809@cs.tcd.ie> Date: Thu, 26 Jul 2007 18:21:12 +0100 From: Stephen Farrell User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Arvel Hathcock Subject: Re: [ietf-dkim] SSP draft suggestions References: <46A5070E.9020101@altn.com> <46A80AB7.3090109@cisco.com> <46A8C9F1.9020909@altn.com> In-Reply-To: <46A8C9F1.9020909@altn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Arvel Hathcock wrote: > > A top-level domain is one that has exactly one component, e.g., "com", > > "org", "uk", or "tv". We also talk about suffixes, which would > > probably include "co.uk", "k12.ca.us", and "edu.au". We mandate not > > querying the top-level domains, since they can be algorithmically > > determined and we really don't want to unnecessarily load the TLD > > servers. > > Thanks much for clearing this up for me. I'm obviously not a DNS > expert. Now that I understand better I see I was wrong and it will be > possible to algorithmically avoid querying the TLDs. > Well, I'm not sure that's entirely true, but it may be good enough, I'm not sure. (We do have some similar text in base though so adding that here as well isn't very different.) S. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 26 13:44:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE7OL-0000ow-Ss for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 13:44:49 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE7OK-00055l-TQ for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 13:44:49 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QHhu6w005213; Thu, 26 Jul 2007 10:44:01 -0700 Received: from harry.mail-abuse.org (Harry.Mail-Abuse.ORG [168.61.5.27]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QHhm06005198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 26 Jul 2007 10:43:48 -0700 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) by harry.mail-abuse.org (Postfix) with ESMTP id AA118414D4; Thu, 26 Jul 2007 10:43:58 -0700 (PDT) In-Reply-To: <46A80AB7.3090109@cisco.com> References: <46A5070E.9020101@altn.com> <46A80AB7.3090109@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B86626C-B126-4DA9-9B8C-C45A7FEACA20@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [ietf-dkim] SSP draft suggestions Date: Thu, 26 Jul 2007 10:44:00 -0700 To: Jim Fenton X-Mailer: Apple Mail (2.752.2) X-Songbird: Clean, Clean Cc: ietf-dkim@mipassoc.org X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e On Jul 25, 2007, at 7:45 PM, Jim Fenton wrote: > Arvel, >> 14) Algorithm 2 - "with one or more answer which is a >> syntactically-valid SSP response" -> "with one or more >> syntactically valid SSP responses" > > Right. This points out that we need to think about what happens if > we get more than one SSP response. Any opinions? If SSP is ever defined for more than just TXT records, then multiple RRs containing multiple syntactically valid responses would be possible. Assuming that rejection should occur when these records differ begs the question, "How will the SSP format evolve?" >> 15) Algorithm 3 has me a little worried. It would prevent the use >> of domains unless they explicitly exist in DNS. So, if I wanted >> to send a message out from message@sms.altn.com I would have to >> make sure and create a DNS A record or something for sms.altn.com >> first right? (sorry, my knowledge of DNS is not so good) > > You should probably have an MX record anyway for sms.altn.com, > especially if that's also the envelope-from address (so it can > receive bounces). It doesn't need to be an A record; any record > type will do. If an SMTP domain is valid, one must assume that this domain can receive messages. There is problem when one assumes that just any record provides evidence of an SMTP's domains existence. To send to this domain, this requires either an _MX_ or _A_ record be published at the SMTP domain. Basing existence upon A records may run afoul of those ISPs and TLDs who inject records when NXDOMAIN would otherwise be returned. Considering the SMTP domain as being valid only when there is also an MX RR has the advantage of actually ensuring a valid SMTP domain. Use of A records for SMTP discovery should be deprecated. When some domain wishes to use random sub-domains, they must also publish a wildcard MX. A query at the random sub-domain will thereby return an MX record. Use of truly random domains precludes the ability to publish policy at a random domain, as it should be. >> 17) Algorithm 4 - "is a top-level domain" how can that be >> determined in practice? I don't think it can can it? If not, >> we're giving algorithmic instruction here that is impossible to >> implement. > > A top-level domain is one that has exactly one component, e.g., > "com", "org", "uk", or "tv". We also talk about suffixes, which > would probably include "co.uk", "k12.ca.us", and "edu.au". We > mandate not querying the top-level domains, since they can be > algorithmically determined and we really don't want to > unnecessarily load the TLD servers. Not querying suffixes is > optional, as the definition for what a "suffix" is, because there > is no formal definition and this is really an optimization. For the ccTLDs, it is common for second and third level domains to be used. Not all domains are published off of a top level domain. Second level domains might then become tempted to publish some SSP record to terminate an inordinate level of SSP searches. Nearly all email sent today will cause an unterminated search SSP record search by those implementing this flawed algorithm. : ( If SSP supported NO MAIL, it would be rather ironic to have SLDs publish an SSP that accurately indicated they do not send email. Use of parent domains to establish policy if _flawed_, and should not be used. >> 18) Algorithm 5 - unless we can figure out how to stop queries at >> top-level domains, Algorithm 5 will send lots of queries to the >> root servers right (.co.uk for example)? > > .co.uk isn't a root server, it's a suffix. Also known as a Second Level Domain, or SLD. These are used in a manner identical to that of a TLD. Just as with the TLD, SLDs MUST NOT be subjected to the resulting high level of unterminated searches. > The root servers are the places you query to find the name servers > for ".com", ".us", ".hr", and so forth. It may send quite a number > of queries to the .co.uk name servers, which is why you may want to > have it in your suffix list, but even if it's not, the number of > queries should be limited by the minimum TTL of the zone it's in > (the negative caching time). The algorithm being suggested demands a list of domains used as registries be published prior to deployment of such an algorithm. I will to help in creating the draft that documents this list. Using MX records to valid existence and deprecating the use of A records for discovery is a better overall strategy however. It would not take long for all domains to publish MX records when their messages are not accepted on occasion as a result. The problem of spam and spoofing is such, that some change to SMTP can and should be demanded. Publishing an MX record is not much to ask. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Thu Jul 26 15:38:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9Ag-0003Vu-6Z for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 15:38:50 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE9Ae-0007Mp-SP for ietf-dkim-archive@lists.ietf.org; Thu, 26 Jul 2007 15:38:50 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QJb9sH031268; Thu, 26 Jul 2007 12:37:18 -0700 Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6QJaxx5031218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Jul 2007 12:37:01 -0700 Received: (qmail 31679 invoked from network); 26 Jul 2007 19:37:09 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 26 Jul 2007 19:37:09 -0000 Date: 26 Jul 2007 19:37:13 -0000 Message-ID: <20070726193713.69210.qmail@simone.iecc.com> From: John Levine To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] SSP draft suggestions In-Reply-To: <46A80AB7.3090109@cisco.com> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Songbird: Clean, Clean Cc: X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: -0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >A top-level domain is one that has exactly one component, e.g., "com", >"org", "uk", or "tv". We also talk about suffixes, which would probably >include "co.uk", "k12.ca.us", and "edu.au". We mandate not querying the >top-level domains, since they can be algorithmically determined and we >really don't want to unnecessarily load the TLD servers. Not querying >suffixes is optional, as the definition for what a "suffix" is, because >there is no formal definition and this is really an optimization. The abuse.net database lookup does an internal walk up the tree looking for an entry (in its own database, not the DNS), and I can report from experience that trying to track delegation point suffixes is an extremely hard problem. Things that look parallel often aren't, e.g., in the various state k12.xx.us domains, in some states there is one agency that serves all the schools so it's a real domain that should have a record, while in others it's just a label. And the list is highly dynamic, e.g., sakhalin.ru used to be a geographic label, similar to a lot of other .ru domains, but now they have a municipal ISP and it has an MX record. R's, John _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 27 10:03:58 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQQA-0000Kd-Bk for ietf-dkim-archive@lists.ietf.org; Fri, 27 Jul 2007 10:03:58 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQQ8-0004rO-OG for ietf-dkim-archive@lists.ietf.org; Fri, 27 Jul 2007 10:03:58 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6RE0srV031502; Fri, 27 Jul 2007 07:01:15 -0700 Received: from [130.129.85.90] ([130.129.85.90]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6RE0gUM031426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 07:00:45 -0700 Message-ID: <46A9FAA3.2020207@bbiw.net> Date: Fri, 27 Jul 2007 09:01:07 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: DKIM IETF WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Subject: [ietf-dkim] DKIM in the local news X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 The Chicago Tribune used to be THE paper of record in Chicago. It had a national reputation. THe quality of the enclosed article suggests it isn't quite at the level it used to be. Still, it's nice to see the DKIM reference... -------- Original Message -------- Subject: [69ATTENDEES] IETF in the local news Date: Fri, 27 Jul 2007 08:53:17 -0500 From: Richard Barnes To: 69attendees@ietf.org This article was in the local paper this morning. Saw it in hard copy on the IETF message board, but here's an electronic version. Copied from: --Richard www.chicagotribune.com/services/newspaper/premium/printedition/Friday/chi-fri_netheadsjul27,0,2758439.story chicagotribune.com Their mission: A better Internet A loose-knit group of 'netheads' gathers in Chicago to tackle some of the problems vexing the Web By Jon Van Tribune staff reporter July 27, 2007 Click here to find out more! The guys who decide how the Internet should work (a few are women) want you to know they don't run the Internet. Nobody does. Despite its tremendous influence on Web technology, the Internet Engineering Task Force goes to great lengths to be loosey-goosey, almost hippylike. It is a purely voluntary group with no dues, no board of directors and no headquarters. "Our mission is to make the Internet work better," said Russell Housley of Herndon, Va., one of some 1,200 engineers from the U.S. and 40 other countries who gathered in Chicago this week to swap ideas. Earlier this year they met in Prague, Czech Republic, and later they will meet in Vancouver. The engineers make suggestions in the form of technical language protocols with arcane acronyms like TCP and DKIM, and they have developed a system for reviewing, approving and publishing standards. But they have no power to enforce anything. Ordinary people who use the Web would have no idea what these engineers talk about -- or that they even exist. But it was not difficult to spot the "netheads" as they gathered in meeting rooms at Chicago's Palmer House Hilton or sat in the hotel's coffee shops and eateries. Nearly every one is tapping away on a laptop computer as he talks, eats or listens to others. "Nothing beats two guys sitting in a bar drawing on a cocktail napkin over a beer," said Housley. One project the engineers have worked on is aimed at decreasing phony e-mail messages asking you to provide your bank, PayPal or some other legitimate-sounding outfit with personal financial information. This form of spam, known as phishing, seeks to trick unsuspecting people by appearing to come from their bank or other place where they do business. A new task force standard attaches a signature to real communications from an actual business, enabling computer servers to identify and discard the phonies. "If a server gets 70 e-mails from PayPal and only five have the real signature, then only five go through and the other 65 don't," said Barry Leiba, who has worked with other engineers for about 30 months on the new standard. "Some companies are starting to adopt the standard, and we hope that within a year people will see fewer phishing spams," said Leiba. "The consumer doesn't have to do anything. Users don't understand the details and don't have answers. We don't want to involve them in this." Leiba's day job is working as a senior technical staff member for Internet messaging with IBM Research. Like most of the engineers who work on Internet standards he does so with his company's blessing. "I'm not here representing IBM," he said. "We are looking for what will improve the Internet, not what promotes our company's interest. Our companies all have a general interest in seeing the Internet work better." While most of the volunteers are engineers, anyone can attend a meeting of the task force, listen to what is said and make suggestions, and while they need not be professional engineers, they do have to have a deep understanding of technical issues and language. "No one is going to ask to see your diploma," said Olaf Kolkman, chief of NLnet Labs in Amsterdam. "Anyone can participate." Kolkman said some people he has never met have made comments and suggestions online that have been incorporated into standards. Some engineers who attend the meetings have no affiliation with any company. A few made big bucks during the dot-com boom, retired early and participate in the task force as a hobby, said Housley. The engineers discuss suggestions and reach what they call a "rough consensus and running code," meaning that most go along with a solution that works. All the work is published online as engineers make comments and revisions. Tasks on their plate include revising standards so that equipment exploring Mars can send photos back to the Internet for researchers to see immediately. Problem is, computers are used to things happening in seconds or milliseconds and it takes about four minutes for a bit to travel from here to Mars, so adjustments are in order. There's also a push to improve Internet telephony so that calls aren't dropped because computers lose track of the identity of the machines they are communicating with. The group, started with a meeting of 21 people in 1986, strives for a type of anarchy that mirrors the Internet itself but does rely on a certain amount of organized support. The Internet Society, a not-for-profit organization based in Reston, Va., provides logistical support for task force gatherings and recruits sponsors. Cell phone-maker Motorola Inc. picked up much of the tab for the Chicago meeting, and AT&T Inc. donated high-speed lines to bolster the Palmer House Hilton's communications systems. Bringing 1,200 Internet-obsessed engineers into a hotel for a week creates a communications demand that would cause an ordinary system to crash in an hour or two, said Steven Schroedl, founder of Verilan Networks in Portland, Ore., who brought a crew of five and literally a ton of equipment to beef up the hotel's wireless Internet. They added switches to a dozen electrical closets in the hotel and installed 30 access points for wireless Internet. "If you brought this group into a hotel without doing this," said Schroedl, "it would be a disaster. At this meeting, it doesn't matter how nice the venue or whether the food is good. It could be Paris or Prague, but if they can't get on the network, all they'll ever remember is how bad it was." - - - Five Internet priorities *Stop phishing spam *Improve communication with Mars probes *Improve telephony *Optimize video transmission *Adjust technology to allow basic functions (like e-mail) in Africa, South America _______________________________________________ 69ATTENDEES mailing list 69ATTENDEES@ietf.org https://www1.ietf.org/mailman/listinfo/69attendees -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Fri Jul 27 10:06:45 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IEQSr-0002Im-4L for ietf-dkim-archive@lists.ietf.org; Fri, 27 Jul 2007 10:06:45 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IEQSq-0004uH-3x for ietf-dkim-archive@lists.ietf.org; Fri, 27 Jul 2007 10:06:45 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6RE5URd000327; Fri, 27 Jul 2007 07:05:30 -0700 Received: from [130.129.85.90] ([130.129.85.90]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6RE1IAT031711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 27 Jul 2007 07:01:21 -0700 Message-ID: <46A9FAC8.3030607@dcrocker.net> Date: Fri, 27 Jul 2007 09:01:44 -0500 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: DKIM IETF WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean Subject: [ietf-dkim] DKIM in the local news X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 The Chicago Tribune used to be THE paper of record in Chicago. It had a national reputation. THe quality of the enclosed article suggests it isn't quite at the level it used to be. Still, it's nice to see the DKIM reference... -------- Original Message -------- Subject: [69ATTENDEES] IETF in the local news Date: Fri, 27 Jul 2007 08:53:17 -0500 From: Richard Barnes To: 69attendees@ietf.org This article was in the local paper this morning. Saw it in hard copy on the IETF message board, but here's an electronic version. Copied from: --Richard www.chicagotribune.com/services/newspaper/premium/printedition/Friday/chi-fri_netheadsjul27,0,2758439.story chicagotribune.com Their mission: A better Internet A loose-knit group of 'netheads' gathers in Chicago to tackle some of the problems vexing the Web By Jon Van Tribune staff reporter July 27, 2007 Click here to find out more! The guys who decide how the Internet should work (a few are women) want you to know they don't run the Internet. Nobody does. Despite its tremendous influence on Web technology, the Internet Engineering Task Force goes to great lengths to be loosey-goosey, almost hippylike. It is a purely voluntary group with no dues, no board of directors and no headquarters. "Our mission is to make the Internet work better," said Russell Housley of Herndon, Va., one of some 1,200 engineers from the U.S. and 40 other countries who gathered in Chicago this week to swap ideas. Earlier this year they met in Prague, Czech Republic, and later they will meet in Vancouver. The engineers make suggestions in the form of technical language protocols with arcane acronyms like TCP and DKIM, and they have developed a system for reviewing, approving and publishing standards. But they have no power to enforce anything. Ordinary people who use the Web would have no idea what these engineers talk about -- or that they even exist. But it was not difficult to spot the "netheads" as they gathered in meeting rooms at Chicago's Palmer House Hilton or sat in the hotel's coffee shops and eateries. Nearly every one is tapping away on a laptop computer as he talks, eats or listens to others. "Nothing beats two guys sitting in a bar drawing on a cocktail napkin over a beer," said Housley. One project the engineers have worked on is aimed at decreasing phony e-mail messages asking you to provide your bank, PayPal or some other legitimate-sounding outfit with personal financial information. This form of spam, known as phishing, seeks to trick unsuspecting people by appearing to come from their bank or other place where they do business. A new task force standard attaches a signature to real communications from an actual business, enabling computer servers to identify and discard the phonies. "If a server gets 70 e-mails from PayPal and only five have the real signature, then only five go through and the other 65 don't," said Barry Leiba, who has worked with other engineers for about 30 months on the new standard. "Some companies are starting to adopt the standard, and we hope that within a year people will see fewer phishing spams," said Leiba. "The consumer doesn't have to do anything. Users don't understand the details and don't have answers. We don't want to involve them in this." Leiba's day job is working as a senior technical staff member for Internet messaging with IBM Research. Like most of the engineers who work on Internet standards he does so with his company's blessing. "I'm not here representing IBM," he said. "We are looking for what will improve the Internet, not what promotes our company's interest. Our companies all have a general interest in seeing the Internet work better." While most of the volunteers are engineers, anyone can attend a meeting of the task force, listen to what is said and make suggestions, and while they need not be professional engineers, they do have to have a deep understanding of technical issues and language. "No one is going to ask to see your diploma," said Olaf Kolkman, chief of NLnet Labs in Amsterdam. "Anyone can participate." Kolkman said some people he has never met have made comments and suggestions online that have been incorporated into standards. Some engineers who attend the meetings have no affiliation with any company. A few made big bucks during the dot-com boom, retired early and participate in the task force as a hobby, said Housley. The engineers discuss suggestions and reach what they call a "rough consensus and running code," meaning that most go along with a solution that works. All the work is published online as engineers make comments and revisions. Tasks on their plate include revising standards so that equipment exploring Mars can send photos back to the Internet for researchers to see immediately. Problem is, computers are used to things happening in seconds or milliseconds and it takes about four minutes for a bit to travel from here to Mars, so adjustments are in order. There's also a push to improve Internet telephony so that calls aren't dropped because computers lose track of the identity of the machines they are communicating with. The group, started with a meeting of 21 people in 1986, strives for a type of anarchy that mirrors the Internet itself but does rely on a certain amount of organized support. The Internet Society, a not-for-profit organization based in Reston, Va., provides logistical support for task force gatherings and recruits sponsors. Cell phone-maker Motorola Inc. picked up much of the tab for the Chicago meeting, and AT&T Inc. donated high-speed lines to bolster the Palmer House Hilton's communications systems. Bringing 1,200 Internet-obsessed engineers into a hotel for a week creates a communications demand that would cause an ordinary system to crash in an hour or two, said Steven Schroedl, founder of Verilan Networks in Portland, Ore., who brought a crew of five and literally a ton of equipment to beef up the hotel's wireless Internet. They added switches to a dozen electrical closets in the hotel and installed 30 access points for wireless Internet. "If you brought this group into a hotel without doing this," said Schroedl, "it would be a disaster. At this meeting, it doesn't matter how nice the venue or whether the food is good. It could be Paris or Prague, but if they can't get on the network, all they'll ever remember is how bad it was." - - - Five Internet priorities *Stop phishing spam *Improve communication with Mars probes *Improve telephony *Optimize video transmission *Adjust technology to allow basic functions (like e-mail) in Africa, South America _______________________________________________ 69ATTENDEES mailing list 69ATTENDEES@ietf.org https://www1.ietf.org/mailman/listinfo/69attendees -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html From ietf-dkim-bounces@mipassoc.org Mon Jul 30 09:29:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFVJg-0003Os-BH for ietf-dkim-archive@lists.ietf.org; Mon, 30 Jul 2007 09:29:44 -0400 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFVJf-0006VZ-Kl for ietf-dkim-archive@lists.ietf.org; Mon, 30 Jul 2007 09:29:44 -0400 Received: from mail.songbird.com (sb7.songbird.com [127.0.0.1]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6UDRYtJ013374; Mon, 30 Jul 2007 06:27:48 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.142]) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id l6UDRN9G013331 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 30 Jul 2007 06:27:24 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6UDRRY1028567 for ; Mon, 30 Jul 2007 09:27:27 -0400 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6UDRQqq454916 for ; Mon, 30 Jul 2007 09:27:27 -0400 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6UDRQ47001913 for ; Mon, 30 Jul 2007 09:27:26 -0400 Received: from poplar (poplar.watson.ibm.com [9.2.40.57]) by d01av03.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6UDRQ3t001904 for ; Mon, 30 Jul 2007 09:27:26 -0400 Received: from dyn9002042047.watson.ibm.com ([9.2.42.47]) by poplar.watson.ibm.com (IMF.2005.07.16.1050.haw) with SMTP ID IMFd1185802046.3441; Mon, 30 Jul 2007 09:27:26 -0400 Message-ID: <46ADE73E.4020806@watson.ibm.com> Date: Mon, 30 Jul 2007 09:27:26 -0400 From: Barry Leiba User-Agent: Thunderbird 2.0.0.5 (Macintosh/20070716) MIME-Version: 1.0 To: DKIM IETF WG Subject: Re: [ietf-dkim] DKIM in the local news References: <46A9FAA3.2020207@bbiw.net> In-Reply-To: <46A9FAA3.2020207@bbiw.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Songbird: Clean, Clean X-BeenThere: ietf-dkim@mipassoc.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IETF DKIM Discussion List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: ietf-dkim-bounces@mipassoc.org Errors-To: ietf-dkim-bounces@mipassoc.org X-SongbirdInformation: support@songbird.com for more information X-Songbird-From: ietf-dkim-bounces@mipassoc.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab > The Chicago Tribune used to be THE paper of record in Chicago. It had a > national reputation. THe quality of the enclosed article suggests it > isn't quite at the level it used to be. Still, it's nice to see the > DKIM reference... BTW, I'll point out that the "quotes" from me were not actually quotes. Jon Van took notes during conversation over lunch, and those are actually his approximations of what I said, based on his notes and his understanding. So please, no quibbling with me about the quotes. Basically, he got it mostly right and it's decent publicity. Dave, will you put it on the dkim.org page? I think the basic link is this: http://www.chicagotribune.com/business/chi-fri_netheadsjul27,0,5876748,full.story ...but I think it'll drift into the archives in 30 days, so I'm not sure how to save it. Maybe I'll print a PDF of the web page and we can post that? Barry _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html