Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0I7u-00022e-8k; Thu, 06 Dec 2007 09:54:58 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1J0I7s-000202-Po for apps-review-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 09:54:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0I7m-0001ek-28 for apps-review@ietf.org; Thu, 06 Dec 2007 09:54:50 -0500 Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0I7l-0002DE-Jb for apps-review@ietf.org; Thu, 06 Dec 2007 09:54:49 -0500 Received: from repmmr01.bea.com (repmmr01.bea.com [10.160.29.71]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB6Esdi1023423; Thu, 6 Dec 2007 06:54:39 -0800 Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr01.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lB6EsbVm013198; Thu, 6 Dec 2007 06:54:38 -0800 Received: from 172.24.29.54 ([172.24.29.54]) by repbex01.amer.bea.com ([10.160.26.98]) with Microsoft Exchange Server HTTP-DAV ; Thu, 6 Dec 2007 14:54:37 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 06 Dec 2007 06:54:30 -0800 From: Eric Burger To: , Message-ID: Thread-Topic: With Respect to SPP Postings on Apps-Review Thread-Index: Acg4F+eJJhT40KQLEdyv4gAWy4mm/w== Mime-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit x-BEA-PMX-Instructions: AV x-BEA-MM: Internal-To-External X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [APPS-REVIEW] With Respect to SPP Postings on Apps-Review X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org A few of these postings had lots of To:'s and Cc:'s in them. It looked to me like people got into the Reply-All habit and were sending "internal" DKIM discussion on the apps-review list. It was raised to me that some of the content was applicable to apps-review. If you got a rejection notice and think your post does need to be cross-posted to apps-review, please either resubmit your post and wait for me to approve the post or (better yet) subscribe to apps-review and resubmit your post. You can always unsubscribe when the DKIM traffic dies down. We would appreciate it, however, if you make sure that cross-postings are really relevant to apps-review. Sorry for any inconvenience this may have caused you. -- Eric, wearily wearing list administrator hat. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0I16-0007K8-Pn; Thu, 06 Dec 2007 09:47:56 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzzGJ-0007mK-F0 for apps-review-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 13:46:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzzGD-0007gg-GP for apps-review@ietf.org; Wed, 05 Dec 2007 13:46:17 -0500 Received: from mtcc.com ([64.142.29.208] helo=fugu.mtcc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzzGB-0006NR-BB for apps-review@ietf.org; Wed, 05 Dec 2007 13:46:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1747; t=1196880374; x=1197744374; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20making=20SSP=20useless=20in=20one=20short=20ste p |Sender:=20 |To:=20=20dcrocker@bbiw.net |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=VWSrAg+c9U8kgRFuXDdtaQR27VJjic0eKfBJAA8qGEo=; b=kjY+7RnFv9teYeUZj6mjwL5adzTWgQConKKvBiEEGMTlWPLLvNwNfNrIpB XKKCSwoGSkikLTdbUXnX48IeYAHIvM9WUzEmyBcIhsX2a0RzOyEGXC5ShD47 +yLFZw1CEKvcDm48ErPqfpEgkPPKQrWrBAAaCLoVkYE3jK/nUE7KI=; Received: from [127.0.0.1] (fugu.mtcc.com [127.0.0.1]) (authenticated bits=0) by fugu.mtcc.com (8.14.1/8.13.8) with ESMTP id lB5IkDIh004207; Wed, 5 Dec 2007 10:46:14 -0800 Message-ID: <4756F1F5.8010006@mtcc.com> Date: Wed, 05 Dec 2007 10:46:13 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <47549320.9000307@dcrocker.net> In-Reply-To: <47549320.9000307@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; v=0.1; dkim=pass, header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); ssp=pass, header.From=mike@mtcc.com X-Spam-Score: -0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-Mailman-Approved-At: Thu, 06 Dec 2007 09:47:55 -0500 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] making SSP useless in one short step X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org [Who is apps-review, and why are they rejecting messages? If this is intended as an apps area review where only Dave gets to post, that's a problem.] Dave Crocker wrote: >> o A "Verifier" is the agent that verifies a message by checking the >> actual signature against the message itself and the public key >> published by the Alleged Signer. The Verifier also looks up the >> Sender Signing Practices published by the domain of the Originator >> Address if the message is not correctly signed by the Alleged >> Originator. > > Again: SSP is now not restricted to unsigned messages. It applies also > to a > potentially very large class of signed messages. In effect, SSP now > appears > to attempting to emulate SPF strictures of correlation among identity > fields. > If SSP is going to have any utility whatsoever, it cannot be defeated by the mere act of signing a message from any random domain. Period. That would be completely and utterly useless, and a complete joke to create such a specification. When a domain says that it signs all of its mail, it means just that. It doesn't mean that maybe on every third thursday that some other domain might sign the mail. It means that the domain in question signs its own mail with its own signatures. That means that you have to know which domain a piece of mail is purporting to be from. The address chosen in the requirements in RFC5016 is the rfc2822.From address. This was not controversial. Why we're rehash that non-argument now is beyond me. > Question: Is DKIM for transit validation or is it for content > authentication? This is a false dilemma. Mike _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwfZ-0007zv-Ll; Wed, 05 Dec 2007 11:00:17 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzfjF-0008Ik-6L for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 16:54:57 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzfjE-0008Ic-TA for apps-review@ietf.org; Tue, 04 Dec 2007 16:54:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfeu-0006wf-VW for apps-review@ietf.org; Tue, 04 Dec 2007 16:50:28 -0500 Received: from mail.winserver.com ([208.247.131.9] helo=winserver.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izfeu-0006Wx-7x for apps-review@ietf.org; Tue, 04 Dec 2007 16:50:28 -0500 Received: by winserver.com (Wildcat! SMTP Router v6.2.452.2) for apps-review@ietf.org; Tue, 04 Dec 2007 16:50:28 -0500 Received: from hdev1 ([72.144.147.204]) by winserver.com (Wildcat! SMTP v6.2.452.2) with ESMTP id 2133463968; Tue, 04 Dec 2007 16:50:26 -0500 Message-ID: <4755CB36.2080904@santronics.com> Date: Tue, 04 Dec 2007 16:48:38 -0500 From: Hector Santos Organization: Santronics Software, Inc. User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Eric Allman References: <47549320.9000307@dcrocker.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 X-TMDA-Confirmed: Tue, 04 Dec 2007 16:54:56 -0500 X-Mailman-Approved-At: Wed, 05 Dec 2007 11:00:17 -0500 Cc: apps-review@ietf.org, dcrocker@bbiw.net, DKIM IETF WG Subject: [APPS-REVIEW] Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Eric Allman responding to Dave's Review: > * Several places you compare this version (unfavorably) to "the original > SSP specification". Which one would that be? There was _policy in DK, > and some stuff in draft-allman-dkim-base that got pulled out, but I > don't recall anything that got further than a very rough draft. Personally, I thought the original "draft" was very clear and concise. It simply lacked the 3rd party issues. > * Several places you refer to reputation. But if I recall correctly we > explicitly avoided using that word, at least in part because it's only > one of a number of mechanisms. Making an assumption that SSP will be > backed up by reputation dramatically expands the scope of the document > in a way that doesn't seem productive. +1 > * You seem to think that doing SSP lookups on third-party signatures > will increase traffic dramatically. I don't think that's at all clear. > By far the majority of the SSP traffic in the short run will be for > messages that have no signature at all. In the longer run it comes down > to what percentage of email traffic is one-to-some (i.e., a first-party > signature) vs. how much goes through mailing lists or other cases that > would have third-party signatures. Of course, the majority of email > will be spam/phishes, and that's a bit harder to predict since they > change so fast, but my first guess is that most of it will be unsigned > and hence require an SSP lookup anyway. +1, There is a double edge sword here and I think it all depends on the type of policy domains begin or leans towards using, which is why I had an "itch" with the "SSP only required if no signature" and "Ignore if Failure" concept. The logical and reasonable premise is: Short Run --> More SSP lookups Long Run --> Less SSP Lookups The long run will include a higher rate of fraud, especially if there is relaxed policies which is the default, hence, most likely the long run will include more or equal me amount unsigned fraud attempts. IOW, the bad guy does not have to adapt to anything related to DKIM or relaxed policies. The more stronger policies exist, theoritcally we will get less fraud. However, two things might occur with the bad: a) Since there are more stronger policies, all he needs to do is create a fake signature. It doesn't have to be correct, and b) begin to target non-supportive DKIM/SSP systems. Therefore, IMO, there might be a tendency to do an SSP first in all cases (of course, the better system will cache this) to address the long run potential of higher fraud. IOW, short or long run, if the majority are relaxed policies, the bad guy doesn't had to anything. He doesn't need to adapt. We only begin to see a shift, a change in pattern as the policies become stronger. > * You seem to think that declaring messages that come from domains that > are not accessible (i.e., a reply would fail with NXDOMAIN) "make(s) it > clear that SSP has moved seriously into more general aspects of > receive-side analysis." However, this step is required to make the > algorithm work; without it there is an obvious security hole. However, > I do agree that a flowchart would help. I think I have a fairly current > around somewhere already, but it's not in ASCII. +1, the same applies to DKIM in the long run. The more DKIM signatures, the more potential for NXDOMAIN key lookups. This is partly why an upfront SSP lookup can assist in the process. The whole theory of DKIM success is based on the premise that in the long run, it will be standard practice to have DKIM "VALID" signatures in the majority of messages. The theory breaks down when the long run includes a signficant amount of invalid signatures. So SSP or no SSP, there will be a drastic overhead problem in HASH computation. In my view, the optimization will make it prudent that: - SSP is lookup first, and - we have stronger policies. The only argument against SSP being looked first, is when we have network wide design assumption of: invalid signatures <<<<< valid signatures. But what if the long run shows? invalid signatures > valid signatures. -- Sincerely Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwfZ-00081k-V7; Wed, 05 Dec 2007 11:00:17 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Izl9z-0000Vg-6T for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 22:42:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izl9y-0000Uf-Po for apps-review@ietf.org; Tue, 04 Dec 2007 22:42:54 -0500 Received: from harry.mail-abuse.org ([168.61.5.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izl9y-0007dj-8A for apps-review@ietf.org; Tue, 04 Dec 2007 22:42:54 -0500 Received: from localhost (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 1EF70267401; Wed, 5 Dec 2007 03:42:51 +0000 (UTC) Message-Id: From: Douglas Otis To: Steve Atkins In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 4 Dec 2007 19:42:50 -0800 References: <47549320.9000307@dcrocker.net> <4755E6AB.2090003@altn.com> X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Wed, 05 Dec 2007 11:00:17 -0500 Cc: DKIM WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Comments on SSP Review BASIC ISSUES X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On Dec 4, 2007, at 4:43 PM, Steve Atkins wrote: > If it starts being deployed and we discover that the SSP false- > positive rate is too high we'll lose a huge amount of time rolling > back deployment of SSPv1 and working on a more realistic SSPv2. > > The SSP false-positive rate will be driven primarily by the DKIM > false-negative rate. As that's a critical piece of data needed to > complete the SSP design to a level of quality suitable for > widespread deployment the wisest course of action would seem to be > to wait until we have wider DKIM deployment and more DKIM > operational experience, and then to gather that data. Any domain asserting All or Strict will also likely cause false- positives when their domain signs for headers other than the From but the From also contains their domain. A domain dedicated to transactional messages could ensure other headers are not signed (perhaps by deprecating i= parameter use to make all signatures ambiguous within the domain). This domain could also ensure only trustworthy entities hold their private keys. One wonders whether keys should have had a scope assertion to constrain which headers are qualified to be signed. The header scope assertion could be placed within SSP with a negligible increase in overhead. As it is now, SSP will be checked in the case where the From header is not signed. An SSP scope could indicate whether an exception should be made. If a key is restricted with g=, a signature for anything other than the From could be noted and serve as a filtering input. It seems doubtful, in the general case, rejecting or placing these messages into a junk folder will be the best choice. As it is now, poor treatment of these messages is likely become common. This issue may also prevent domain's wishing to assure recipients, to be unable to consistently use the i= parameter. :^( A key or SSP scope policy could indicate only From headers are valid, and applied as a follow-on solution when ignoring i= parameters prove problematic. Being generous in what is accepted for valid signatures from the From domain seems like the best solution. John Levine's suggestion of using i= identities as opaque identities is very attractive, but this also prevents a domain of ever indicating they sign everything when the definition of signed MUST include matches with the i= parameter. Perhaps there should be a draft created to offer a u= extension to hold opaque identifiers. This would offer a consistent signed location where the domain and identifier are assured to be related. -Doug _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwfZ-000800-O4; Wed, 05 Dec 2007 11:00:17 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IziM4-0006bd-AZ for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 19:43:12 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IziM3-0006aF-VK for apps-review@ietf.org; Tue, 04 Dec 2007 19:43:11 -0500 Received: from fruitbat.wordtothewise.com ([208.187.80.135] helo=m.wordtothewise.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IziM3-00070j-Ar for apps-review@ietf.org; Tue, 04 Dec 2007 19:43:11 -0500 Received: from [10.3.2.34] (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 0555F4F8008; Tue, 4 Dec 2007 16:43:10 -0800 (PST) In-Reply-To: <4755E6AB.2090003@altn.com> References: <47549320.9000307@dcrocker.net> <4755E6AB.2090003@altn.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Atkins Date: Tue, 4 Dec 2007 16:43:08 -0800 To: DKIM WG X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 05 Dec 2007 11:00:17 -0500 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Comments on SSP Review BASIC ISSUES X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On Dec 4, 2007, at 3:45 PM, Arvel Hathcock wrote: > Hi! > > I'm sure others will make more intelligent comments but I have a > few that I'd like to offer. > > First, text in the SSP draft states repeatedly that receivers are > free to dispose of their messages as they see fit so I think that > certain and frequent comments in the Review to the contrary are > incorrect. > >> In general, the draft needs to consider adoption incentives for >> receivers. > > SSP offers itself as a means to detect unauthorized domain use. > That is sufficient incentive for adoption by receivers. It doesn't provide a reliable means to detect unauthorized domain use. That alone is sufficient reason for receivers (and many senders) to be skeptical about deployment. How unreliable it is we don't know yet, but until we have more operation experience with DKIM it's reasonable to assume the worst. If it starts being deployed and we discover that the SSP false- positive rate is too high we'll lose a huge amount of time rolling back deployment of SSPv1 and working on a more realistic SSPv2. The SSP false-positive rate will be driven primarily by the DKIM false-negative rate. As that's a critical piece of data needed to complete the SSP design to a level of quality suitable for widespread deployment the wisest course of action would seem to be to wait until we have wider DKIM deployment and more DKIM operational experience, and then to gather that data. (In parallel with gathering that data we could also take more time to deal with some of the other issues with SSP semantics in a broader forum, with more input from from real-world senders and receivers, rather than the small subset currently looking at it). Cheers, Steve _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwfZ-000805-QL; Wed, 05 Dec 2007 11:00:17 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzjXa-00025k-Bb for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 20:59:10 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzjXa-00025a-29 for apps-review@ietf.org; Tue, 04 Dec 2007 20:59:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzjTu-0007nn-Kw for apps-review@ietf.org; Tue, 04 Dec 2007 20:55:22 -0500 Received: from c60-outbound.ironport.com ([63.251.108.116] helo=smtp2-outbound.ironport.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzjTt-0002SG-SE for apps-review@ietf.org; Tue, 04 Dec 2007 20:55:22 -0500 DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Received:X-MimeOLE:Content-class:MIME-Version: Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:References: From:To:Cc:Return-Path:X-OriginalArrivalTime; b=lUwax5cCHOBneDdlorcflMPoXjqr5OUiQhz8VT062fQ5KJndSK+PZomY qYkRjTEHNY/HFvfr68wIbbu2j7M6iQ==; Received: from vader.ironportsystems.com ([10.1.1.112]) by smtp2-outbound.ironport.com with ESMTP; 04 Dec 2007 17:55:22 -0800 Received: from dooku.ironportsystems.com ([10.1.1.49]) by vader.ironportsystems.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 17:55:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 17:53:58 -0800 Message-ID: <60A9EDD76DBBFE48ABE4FE35324BBB8202D68709@dooku.ironportsystems.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] Comments on SSP Review BASIC ISSUES Thread-Index: Acg22ITMmoub9/PBSg+ytjWDeVkINQABmvIg References: <47549320.9000307@dcrocker.net> <4755E6AB.2090003@altn.com> From: "Patrick Peterson" To: "Steve Atkins" , "DKIM WG" X-OriginalArrivalTime: 05 Dec 2007 01:55:14.0198 (UTC) FILETIME=[E07E6360:01C836E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-TMDA-Confirmed: Tue, 04 Dec 2007 20:59:10 -0500 X-Mailman-Approved-At: Wed, 05 Dec 2007 11:00:17 -0500 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] RE: [ietf-dkim] Comments on SSP Review BASIC ISSUES X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org =20 > On Dec 4, 2007, at 3:45 PM, Arvel Hathcock wrote: > > SSP offers itself as a means to detect unauthorized domain use. =20 > > That is sufficient incentive for adoption by receivers. >=20 > It doesn't provide a reliable means to detect unauthorized domain =20 > use. That alone is sufficient reason for receivers (and many=20 > senders) =20 > to be skeptical about deployment. Myself and many others believe it offers a means to detect unauthorized domain use that justifies its use. I believe it is reliable "enough" but of course it's not 100% reliable. We disagree on this point but this isn't a problem at all as we can both have our way with SSP: - I encourage and support skeptics like yourself to avoid use of strict/deny policies and to disregard the use of strict/deny policies. - I encourage those agreeing with Arvel, myself and many others to use strict/deny policies as appropriate as a means to detect unauthorized domain use. Everyone can make their own decision about the applicability and utility of this technique and vote with their SSP policies. Take strict/deny policies away from your mail stream but please don't take strict/deny away from proponents' mail stream because you don't think it's reliable enough.=20 > How unreliable it is we don't know yet, but until we have more =20 > operation experience with DKIM it's reasonable to assume the worst. * see comment below =20 > If it starts being deployed and we discover that the SSP false-=20 > positive rate is too high we'll lose a huge amount of time rolling =20 > back deployment of SSPv1 and working on a more realistic SSPv2. No. If someone chooses a strict/deny policy and it has a high false-positive rate receivers can simply ignore it as you are planning to do. If someone deploys strict/deny and finds it has a high false-positive rate they can change to unknown/process. A change in SSP policy is all that's necessary, not a new SSPv2. =20 > The SSP false-positive rate will be driven primarily by the DKIM =20 > false-negative rate. As that's a critical piece of data needed to =20 > complete the SSP design to a level of quality suitable for=20 > widespread =20 > deployment the wisest course of action would seem to be to=20 > wait until =20 > we have wider DKIM deployment and more DKIM operational experience, =20 > and then to gather that data. * taken together with unreliable comment above... Yahoo and PayPal have done the largest scale implementation of a back-channel strict/deny for DK. PayPal spoke at MAAWG on their success and said he had business benefit. The false positives would be much lower with DKIM than with DK. Other banks have deployed DKIM and found the FP rate to be acceptable to them based on their criteria. I believe the DKIM interoperability summit is the largest test of this kind and results were encouraging. There was no official pronouncement or false positive measurement but I believe the results didn't leave anyone to believe driving the FP rate to an acceptable level was not possible in the near future. Here's the closest thing I found to a DKIM reliability pronouncement: http://dkim.org/news/DKIM%20Interop%20Event%20PR%2011_06_07.htm "We have demonstrated that DKIM is easy to add to an email service and that its use of cryptographic technology provides a strong basis for knowing received email really is associated with the organization that claims to have sent it." - Dave Crocker (quote excerpt) "We learned a lot by participating; not the least of which is that DKIM just works," said Arvel Hathcock, Founder and CEO of Alt-N Technologies, and host of the event. "The testing performed by all participants revealed no significant barriers to adoption or use." http://altnblogs.com/arvel/ Finally, I was struck by just how well this DKIM stuff actually does work. It really does deliver as advertised and we found no significant technological problems which would hinder adoption or deployment. If you have better data on DKIM reliability please share. Of course if you think it's unreliable then publish unknown/process for mail you send and ignore SSP for mail you receive. pat _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwfZ-0007zr-Jc; Wed, 05 Dec 2007 11:00:17 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzeGm-0003SB-QO for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 15:21:28 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzeGm-0003Rs-GC for apps-review@ietf.org; Tue, 04 Dec 2007 15:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzeF9-00020Z-V7 for apps-review@ietf.org; Tue, 04 Dec 2007 15:19:47 -0500 Received: from knecht.neophilic.com ([64.81.247.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzeF7-0007iA-HA for apps-review@ietf.org; Tue, 04 Dec 2007 15:19:47 -0500 Received: from [10.0.2.35] ([10.0.2.35]) by knecht.neophilic.com (8.14.1/8.13.6) with ESMTP id lB4KJL8H057514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 4 Dec 2007 12:19:21 -0800 (PST) (envelope-from eric@neophilic.com) Date: Tue, 04 Dec 2007 12:19:40 -0800 From: Eric Allman To: dcrocker@bbiw.net Message-ID: In-Reply-To: <47549320.9000307@dcrocker.net> References: <47549320.9000307@dcrocker.net> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Status: No, score=-1.8 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_FUTURE_24_48 autolearn=no version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on knecht.neophilic.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-TMDA-Confirmed: Tue, 04 Dec 2007 15:21:28 -0500 X-Mailman-Approved-At: Wed, 05 Dec 2007 11:00:17 -0500 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org I'm going to reply to this message twice. This is a short note, but given the size of your critique and the fact that we got less than 24 hours to look at it before the meeting, I'm planning on doing a more detailed reply later. Briefly, please consider Patrick Peterson's response dated 12/4 02:18:51 AM to be included here. I agree with the gist of everything he and other people such as Scott and Wietse have to say. * Several places you compare this version (unfavorably) to "the original SSP specification". Which one would that be? There was _policy in DK, and some stuff in draft-allman-dkim-base that got pulled out, but I don't recall anything that got further than a very rough draft. * You obviously dislike the way SSP handles multiple From field addresses, and yet you offer no alternative. I don't like it either, but just complaining isn't constructive. I will point out that using Sender: was considered and rejected, so unless we want to reexamine that, that's not the answer either. * I agree with the folks who say that "Suspicious" is simply a defined term in this document, and (as in any contract) it doesn't necessarily carry the connotative baggage of broader language. None the less I'm not wedded to that word; we can call it "Orange" if we want. * Several places you refer to reputation. But if I recall correctly we explicitly avoided using that word, at least in part because it's only one of a number of mechanisms. Making an assumption that SSP will be backed up by reputation dramatically expands the scope of the document in a way that doesn't seem productive. * You seem to think that doing SSP lookups on third-party signatures will increase traffic dramatically. I don't think that's at all clear. By far the majority of the SSP traffic in the short run will be for messages that have no signature at all. In the longer run it comes down to what percentage of email traffic is one-to-some (i.e., a first-party signature) vs. how much goes through mailing lists or other cases that would have third-party signatures. Of course, the majority of email will be spam/phishes, and that's a bit harder to predict since they change so fast, but my first guess is that most of it will be unsigned and hence require an SSP lookup anyway. * You suggest moving _ssp out of the _domainkey subdomain. However, I think it's worthwhile having it there in the event that the _domainkey subdomain is delegated. It seems logical to keep everything together. * You seem to think that declaring messages that come from domains that are not accessible (i.e., a reply would fail with NXDOMAIN) "make(s) it clear that SSP has moved seriously into more general aspects of receive-side analysis." However, this step is required to make the algorithm work; without it there is an obvious security hole. However, I do agree that a flowchart would help. I think I have a fairly current around somewhere already, but it's not in ASCII. OK, that's it for comments for now. And really, this /is/ the short version. eric _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwdO-0006jf-Ih; Wed, 05 Dec 2007 10:58:02 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzhSk-0003HF-SD for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:46:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhSk-0003Gs-8i for apps-review@ietf.org; Tue, 04 Dec 2007 18:46:02 -0500 Received: from c3po.altn.com ([65.240.66.134]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzhSj-0003Mn-FI for apps-review@ietf.org; Tue, 04 Dec 2007 18:46:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=altn.com; s=c3po; l=5584; t=1196811960; x=1197416760; q=dns/txt; h=DomainKey-Signature: Received:VBR-Info:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding; bh=2awHvT5+Pke2NB9nv1Ax166GBA0nISANgD CAmJEuhtc=; b=WIuZjztxh6gvFR4LkU9VPRV6W2+8EGKovee9IwH50tjCE4IHjS M4cPhl8QD275LA1kYX+G98Y1oX4staUkegOxw5Z6FlRLoBJFv7UPot3a9AeMcnry lZLUAo6kDo29hanA+siuPZ8J/kRnWQHHF9qrknSzx9MFmDCJbxE43xPu0= DomainKey-Signature: a=rsa-sha1; s=c3po; d=altn.com; c=nofws; q=dns; h=message-id:from; b=Zhvoke/ilckarc+cwCy0BpHvfPsYMXXk672hBC+WFGCTtm7mS69flogzQ8ph IDZMDqbQFPE4/kiZ8Q5U8bLyPOiRr4Y1g1zX5sW8IOXGwVZKp8ZCijQ6p zUvt2oP1Y4TW04uQllx9byZU8gWddp/OKdPPsxrHEyJqqfrwuS4beY=; Received: from [127.0.0.1] by altn.com (MDaemon PRO v10.0.0a) with ESMTP id md50002556374.msg for ; Tue, 04 Dec 2007 17:45:59 -0600 VBR-Info: md=altn.com; mc=all; mv=vbr.emailcertification.org; X-Spam-Processed: c3po.altn.com, Tue, 04 Dec 2007 17:45:59 -0600 (not processed: message from trusted or authenticated source) X-MDPtrLookup-Result: pass dns.ptr=cpe-76-187-127-11.tx.res.rr.com (ip=76.187.127.11) (c3po.altn.com) X-MDHeloLookup-Result: hardfail smtp.helo=[127.0.0.1] (does not match 76.187.127.11) (c3po.altn.com) X-Authenticated-Sender: Arvel.Hathcock@altn.com X-HashCash: 1:21:071204:md50002556374::ekBv+aGtB2TW9NSe:00002M96 X-MDRemoteIP: 76.187.127.11 X-Return-Path: prvs=1858c51697=arvel.hathcock@altn.com X-Envelope-From: arvel.hathcock@altn.com X-MDaemon-Deliver-To: apps-review@ietf.org Message-ID: <4755E6AB.2090003@altn.com> Date: Tue, 04 Dec 2007 17:45:47 -0600 From: Arvel Hathcock User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: dcrocker@bbiw.net References: <47549320.9000307@dcrocker.net> In-Reply-To: <47549320.9000307@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MDAV-Processed: c3po.altn.com, Tue, 04 Dec 2007 17:46:00 -0600 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 X-Mailman-Approved-At: Wed, 05 Dec 2007 10:58:01 -0500 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Comments on SSP Review BASIC ISSUES X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Hi! I'm sure others will make more intelligent comments but I have a few that I'd like to offer. First, text in the SSP draft states repeatedly that receivers are free to dispose of their messages as they see fit so I think that certain and frequent comments in the Review to the contrary are incorrect. > In general, the draft needs to consider adoption incentives for > receivers. SSP offers itself as a means to detect unauthorized domain use. That is sufficient incentive for adoption by receivers. > My guess is that such an analysis will show that there is a relatively > small set of publishers and receivers who are highly motivated > to implement the more advanced features -- advanced relative to > earlier SSP drafts -- I don't know what you consider "the more advanced features" but I can speak with some authority for small receivers and they would welcome the unauthorized domain use detection capability which SSP provides. > In my opinion, the draft should be broken into an initial core, with > optional extensions. The core should define the publication mechanism > and the smallest set of features that are deemed useful and likely > to receive a broad base of initial adoption. No, no. Let's resist this urge. The "smallest set of features that are deemed useful" etc are what many believe the existing draft already is - so there's nothing to split out. > the protocol is not constrained to "interpret" with respect to defining > what the published information means, but rather is meant to guide, or even > mandate, how the mail receive-side participant should handle messages. There are several statements within the document to the contrary. How do you reconcile those with your assertion above? > There have been some Internet publication mechanisms used that might be > thought to be similar to SSP. Most are third-party, centrally controlled > attribute or quality databases. These are an entirely different > administrative and information models from the self-published directive > nature of SSP. You're speaking here of BL's and SPF. The existence and ubiquitous use of which is absolute proof of at least three things: 1. the idea of offering input into receive side filters is not unprecedented 2. the network infrastructure is very robust with respect to queries 3. the world has embraced the concept of DNS-based input into the message decision making matrix. Those are precisely the criterion upon which we can reliably presume the mechanical and adoptive success of SSP. > The original SSP specification applied only to unsigned messages. Not sure what you mean by "original SSP specification" but you state this more than once in your Review. I believe this to be errant but it's not interesting. Whatever changes may have occurred were accomplished through the WG process and so were not done in secret. > If a signer has a good reputation, then why is that not > sufficient for enabling delivery? In other words, with a > signature of a domain with a good reputation, what threats is > SSP trying to protect against? Perhaps it is sufficient and when it is, there are some steps in the SSP algorithm (all steps after step 1) which are a waste of time/resources. I've struggled with this myself and am not altogether satisfied. An easy optimization would be to add "Verifier Acceptable Third-Party Signatures (VATPS)" to the text of step 1. But, I don't think this problem amounts to the receiver being "told what to do" by the domain owner. In other words, SSP's requirement that the algorithm in 4.4 continue beyond step 1 even when a VATPS is detected early is an inefficiency in the algorithm. If a receiver knows that they are always going to accept messages with a VATPS, then queries to determine whether the policy of the From domain agrees with this practice are pointless. Now, Jim will have something to say to clarify this issue further I'm sure (hoping) :) > The draft does note that initial receive-side adopters of SSP > will find no SSP DNS record. However the draft does not > address the adoption and use impact of being expected to make > a query that will almost always fail for a significant number > of years into the future. What is the significance of this observation? The DNS infrastructure has proven to be very robust and there are routinely now a half-dozen or more queries performed on each and every message received these days. If the DNS infrastructure is incapable of scaling for one more query per message then I suggest we've got much bigger problems to be working on than this WG is tasked with. Is there something especially negative about a failed query that I don't understand? > In reviewing the apparent semantics of full SSP use, I believe > it seeks to move a DKIM signature, which uses the same domain > name as is in the From field, into the realm of declaring content > to be valid. I see absolutely no basis for such a belief. Please explain. Please define both "content" and "valid". > 8. Filter Engine vs. End-user as SSP Target > > The current SSP has re-introduced a range of assumptions about use with > human recipients, and has used those assumptions for dictating specification > details. The specification needs to remove all consideration of human > issues or else to provide substantial empirical basis for its inclusion. What are these assumptions? Arvel _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhBd-00060O-8m; Tue, 04 Dec 2007 18:28:21 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzhBb-0005lx-PF for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:28:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzhBb-0005je-CP for apps-review@ietf.org; Tue, 04 Dec 2007 18:28:19 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzhBa-0006Sp-W9 for apps-review@ietf.org; Tue, 04 Dec 2007 18:28:19 -0500 Received: from [130.129.84.220] ([130.129.84.220]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB4NRoG4015031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 15:27:51 -0800 Message-ID: <4755E313.6010302@dcrocker.net> Date: Tue, 04 Dec 2007 15:30:27 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jim Fenton References: <47549320.9000307@dcrocker.net> <475585A2.8040600@mtcc.com> <4755D0D4.4000005@dcrocker.net> <4755D4B8.8060807@cisco.com> In-Reply-To: <4755D4B8.8060807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Tracing SSP's paradigm change X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Jim Fenton wrote: > In the absence of a valid DKIM signature on behalf of the "From" address > [RFC2822], the verifier of a message MUST determine whether messages from a > particular sender are expected to be signed, and what signatures are > acceptable. What's proving interesting is how completely the implication of this seems to have been missed by quite a few participants. I'l continue to repeat that I haven't found the working group discussion of this implication. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izh7z-00044y-HI; Tue, 04 Dec 2007 18:24:35 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Izh7y-00042O-0g for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 18:24:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izh7x-00042B-NC for apps-review@ietf.org; Tue, 04 Dec 2007 18:24:33 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izh7w-00067n-6I for apps-review@ietf.org; Tue, 04 Dec 2007 18:24:33 -0500 Received: from [130.129.84.220] ([130.129.84.220]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB4NO32T013628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 15:24:04 -0800 Message-ID: <4755E230.8010600@dcrocker.net> Date: Tue, 04 Dec 2007 15:26:40 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael Thomas References: <47549320.9000307@dcrocker.net> <475585A2.8040600@mtcc.com> <4755D0D4.4000005@dcrocker.net> <4755D244.9090309@mtcc.com> In-Reply-To: <4755D244.9090309@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Re: Tracing SSP's paradigm change X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Michael Thomas wrote: > Dave Crocker wrote: >> On reviewing the working group archive, I have not succeeded in finding >> any discussion either of changing the SSP paradigm to apply to signed >> message or of the problematic selection of the rfc2822.From field, rather >> than rfc2822.Sender field domain. >> >> I recall making a point a number of times in the working group, verifying >> that the group agreed that SSP applied (only) to unsigned messages. > > > RFC 5016, section 5.3 requirement #1: > > 1. SSP MUST be able to make practices and expectation assertions about the > domain part of a [RFC 2822].From address in the context of DKIM. SSP will > not make assertions about other addresses for DKIM at this time. > > Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. > > I just checked and this requirement has been in the requirements since the > very first draft. If you objected, it apparently didn't get much consensus. That relates to using .From. How does it related to the application of SSP for signed messages, and where is the indication that this implication was understood by the community? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfyK-0001UD-Fu; Tue, 04 Dec 2007 17:10:32 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzfyI-0001Q3-Db for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:10:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzfyI-0001Pm-3B for apps-review@ietf.org; Tue, 04 Dec 2007 17:10:30 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzfyH-0008DW-Jj for apps-review@ietf.org; Tue, 04 Dec 2007 17:10:30 -0500 Received: from [130.129.84.220] ([130.129.84.220]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB4M9x9k019292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Dec 2007 14:10:00 -0800 Message-ID: <4755D0D4.4000005@dcrocker.net> Date: Tue, 04 Dec 2007 14:12:36 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael Thomas References: <47549320.9000307@dcrocker.net> <475585A2.8040600@mtcc.com> In-Reply-To: <475585A2.8040600@mtcc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Tracing SSP's paradigm change X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Michael Thomas wrote: > Dave Crocker wrote: > >> 3. Scope and scale of query traffic >> >> SSP originally was constrained to apply only to unsigned mail. The >> current specification applies to unsigned messages *and* signed messages >> where the DKIM i= domain name does not match the rfc2822.From >> domain. This is a considerable change in the nature -- and potentially >> a considerable change in the amount of query traffic -- that SSP causes. > > This has not changed in years. Maybe you've just become aware of it. And > the problem here remains with unsigned traffic. Third party signatures are > very rare beasts. The requirement to have i= match From domain was added between the -02 and -03 versions, sometime during Fall 06 and Winter 07. On reviewing the working group archive, I have not succeeded in finding any discussion either of changing the SSP paradigm to apply to signed message or of the problematic selection of the rfc2822.From field, rather than rfc2822.Sender field domain. I recall making a point a number of times in the working group, verifying that the group agreed that SSP applied (only) to unsigned messages. >> The draft does note that initial receive-side adopters of SSP will find >> no SSP DNS record. However the draft does not address the adoption and >> use impact of being expected to make a query that will almost always fail >> for a significant number of years into the future. > > There is a trivial mechanism that can cut down SSP lookups to almost > nothing: don't query domains from which you've never received a valid DKIM > signature. You are suggesting that a problematic design which imposes undue overhead is remedied by a hack that has no long-term experience? (By contrast, a design that relies on caching would be using a well-understood and accepted mechanism which is accepted as altering query dynamics reliably, though not perfectly.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcXH-0003dn-NS; Tue, 04 Dec 2007 13:30:24 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzayV-0005WH-DQ for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:50:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzayV-0005W3-3Q for apps-review@ietf.org; Tue, 04 Dec 2007 11:50:23 -0500 Received: from harry.mail-abuse.org ([168.61.5.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzayR-0005RN-Ix for apps-review@ietf.org; Tue, 04 Dec 2007 11:50:23 -0500 Received: from localhost (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 8669A267416; Tue, 4 Dec 2007 16:50:18 +0000 (UTC) From: Douglas Otis To: dcrocker@bbiw.net In-Reply-To: <47549320.9000307@dcrocker.net> X-Priority: 2 (High) References: <47549320.9000307@dcrocker.net> Message-Id: <858ED170-DA26-417D-B94C-7B53F09665E6@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Date: Tue, 4 Dec 2007 08:50:17 -0800 X-Mailer: Apple Mail (2.915) X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 X-Mailman-Approved-At: Tue, 04 Dec 2007 13:30:23 -0500 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org On Dec 3, 2007, at 3:37 PM, Dave Crocker wrote: > 3. Scope and scale of query traffic > > SSP originally was constrained to apply only to unsigned mail. The > current specification applies to unsigned messages *and* signed > messages where the DKIM i= domain name does not match the > rfc2822.From domain. This is a considerable change in > the nature -- and potentially a considerable change in the amount of > query traffic -- that SSP causes. The desire here is to qualify the From header for transactional messages. > The draft does note that initial receive-side adopters of SSP will > find no SSP DNS record. However the draft does not address the > adoption and use impact of being expected to make a query that will > almost always fail for a significant number of years into the future. A policy statement that can be applied more broadly, where benefits extend beyond just qualifying the From header, would suit more than transactional messages. Adding Scope to policy could more broadly apply to all originating headers when handling "normal" messages. This policy could also clarify what is implied by use of the i= parameter. The current use of the i= parameter is clumsy. Matching the i= parameter precludes use of a g= restricted keys from signing Sender headers to spoof a From header. The ALL or STRICT assertions must constrain the i= parameter to disqualify restricted keys not signing the From header. Adding scope can eliminate these constraints. Attempts at providing a minimal set of assertions has lead to this very sub-optimal policy mechanism this is only suitable for transactional messages. Most domains use the full set of originating headers. There is also a need to partition policy to suit how email is being used. Who is signing is the place to establish such a partition. Users SHOULD NOT see well-known domains use other domains to establish different policies. Policy partitions can transparent by introducing Scope and a TPA-SSP label. These two changes offer significant benefits. -Doug _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcXI-0003fJ-94; Tue, 04 Dec 2007 13:30:24 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1Izazs-0006Bw-An for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:51:48 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izazr-0006Bn-WA for apps-review@ietf.org; Tue, 04 Dec 2007 11:51:48 -0500 Received: from mtcc.com ([64.142.29.208] helo=fugu.mtcc.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izazr-0001LT-Gc for apps-review@ietf.org; Tue, 04 Dec 2007 11:51:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1100; t=1196787106; x=1197651106; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[ietf-dkim]=20Review=20of=20DKIM=20Send er=20Signing=20Practices=09(draft-ietf-dkim-ssp-01) |Sender:=20 |To:=20=20dcrocker@bbiw.net |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=AtqNz5pocO5PYzSm407upkFXQq2/BI74YKPedvJEeXY=; b=kvcgRU23ZUJIefn1+7fAvHjW0lOxmSEepcdluInWAaYzaQ6qw99OUxDyjV nxHpHkJpSZiRknPNu0XQ0EufCnbxwP5T5EaIVSao/MIBTOm9Ped6rwVRPPZH nFF+Svep3r0cAQkhAJEgamSxoF0rpD4v/JaAe6V/5IKpwGFIq7W4s=; Received: from [127.0.0.1] (fugu.mtcc.com [127.0.0.1]) (authenticated bits=0) by fugu.mtcc.com (8.14.1/8.13.8) with ESMTP id lB4Gpkuk019302; Tue, 4 Dec 2007 08:51:46 -0800 Message-ID: <475585A2.8040600@mtcc.com> Date: Tue, 04 Dec 2007 08:51:46 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <47549320.9000307@dcrocker.net> In-Reply-To: <47549320.9000307@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; v=0.1; dkim=pass, header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); ssp=pass, header.From=mike@mtcc.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Tue, 04 Dec 2007 13:30:23 -0500 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Dave Crocker wrote: > 3. Scope and scale of query traffic > > SSP originally was constrained to apply only to unsigned mail. The current > specification applies to unsigned messages *and* signed messages where the > DKIM i= domain name does not match the rfc2822.From domain. > This > is a considerable change in the nature -- and potentially a considerable > change in the amount of query traffic -- that SSP causes. This has not changed in years. Maybe you've just become aware of it. And the problem here remains with unsigned traffic. Third party signatures are very rare beasts. > The draft does note that initial receive-side adopters of SSP will find > no SSP > DNS record. However the draft does not address the adoption and use > impact of > being expected to make a query that will almost always fail for a > significant > number of years into the future. There is a trivial mechanism that can cut down SSP lookups to almost nothing: don't query domains from which you've never received a valid DKIM signature. Mike _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcXH-0003cD-Gc; Tue, 04 Dec 2007 13:30:23 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzV37-0000Au-4C for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 05:30:45 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzV36-00009f-QH for apps-review@ietf.org; Tue, 04 Dec 2007 05:30:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzUsx-0004n2-SG for apps-review@ietf.org; Tue, 04 Dec 2007 05:20:15 -0500 Received: from a50.ironport.com ([63.251.108.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzUsw-0003OZ-6A for apps-review@ietf.org; Tue, 04 Dec 2007 05:20:15 -0500 DomainKey-Signature: s=key512; d=ironport.com; c=nofws; q=dns; h=Received:Received:X-MimeOLE:Content-class:MIME-Version: Content-Type:Content-Transfer-Encoding:Subject:Date: Message-ID:In-Reply-To:X-MS-Has-Attach: X-MS-TNEF-Correlator:Thread-Topic:Thread-Index:References: From:To:Cc:Return-Path:X-OriginalArrivalTime; b=EZzLWsM0jlBPER1g6N68COIbtJE1LcXxQsuog8vaDLgSsn/mEa9VCvVY VzcfcMVPPWrF602ifuOWS37KTDc5dA==; Received: from vader.ironportsystems.com ([10.1.1.112]) by a50.ironport.com with ESMTP; 04 Dec 2007 02:20:13 -0800 Received: from dooku.ironportsystems.com ([10.1.1.49]) by vader.ironportsystems.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 02:20:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Dec 2007 02:18:51 -0800 Message-ID: <60A9EDD76DBBFE48ABE4FE35324BBB8202D685B9@dooku.ironportsystems.com> In-Reply-To: <47549320.9000307@dcrocker.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01) Thread-Index: Acg2BX5J9z8hzTtyT0WAKm95VaCHnAAUryMg References: <47549320.9000307@dcrocker.net> From: "Patrick Peterson" To: , "DKIM IETF WG" X-OriginalArrivalTime: 04 Dec 2007 10:20:06.0651 (UTC) FILETIME=[3DCA24B0:01C8365F] X-Spam-Score: -5.3 (-----) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 X-TMDA-Confirmed: Tue, 04 Dec 2007 05:30:44 -0500 X-Mailman-Approved-At: Tue, 04 Dec 2007 13:30:23 -0500 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] RE: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org My comments inline below. They can be summarized as follows: 1. SSP does not dictate receiver behavior. SSP bends over backwards to state receiver behavior is at receivers' discretion. If someone can find someplace where SSP dictates receiver behavior please identify it so it can be fixed. 2. Some IETF particiants believe certain SSP statements such as "strict" and "deny" are not useful SSP constructs for them. Some are explicit that these constructs would not be used by their own mail servers. However there is a large part of the Internet community that desires these constructs. The brilliance of "strict" and "deny as defined in SSP is that a strict/deny proponent like myself can build a system using the strict/deny data provided by other strict/deny proponents' SSP records AND strict/deny opponents can simply publish "unknown", "all" and "process" policies and then use their discretion to ignore results related to strict/deny. Everybody wins! I believe it would be an epic mistake for the strict/deny opponents to prevent others from utilizing these capabilities. I have no desire to prevent someone from ignoring strict/deny at their discretion; why can't I have a syntax I desire to state strict/deny for those who will use it? pat PS: SSP does not dicatate receiver behavior :) > In general, the draft needs to consider adoption incentives=20 > for receivers. My > guess is that such an analysis will show that there is a=20 > relatively small set > of publishers and receivers who are highly motivated to=20 > implement the more > advanced features -- advanced relative to earlier SSP drafts=20 > -- but that true, > Internet-scale adoption will be elusive for quite some time. I strongly disagree. There are a significant number of large receivers that are highly motivated to adopt the draft. Take one example: Y! has been public about their work with PayPal to ensure non-delivery of unsigned or invalidly signed DK messages. (I know this is DK but the incentive of SSP is the same for DK or DKIM.) I have been very public about IronPort's desire to implement SSP based on the proxied desires of our customers. The 100 US Financial Services Roundtable companies (BITS) have also been public about their desires in this area. > In my opinion, the draft should be broken into an initial=20 > core, with optional > extensions. The core should define the publication mechanism=20 > and the smallest > set of features that are deemed useful and likely to receive=20 > a broad base of > initial adoption. The extensions would target the smaller=20 > set of adopters who > are viewed as being strongly motivated for these enhancement.=20 > The core would > be appropriate for direct standardization, while the options would be > experimental. Again disagree. I feel the extensions are critical. > 1. Signer/Validator practices "negotiation" scope >=20 > SSP's description of itself as including "how verifiers=20 > should... interpret > those results" states a scope of protocol semantics that is=20 > new to the IETF; > the protocol is not constrained to "interpret" with respect=20 > to defining what > the published information means, but rather is meant to guide, or even > mandate, how the mail receive-side participant should handle messages. This is not true. draft-ietf-dkim-ssp-01 states: "deny Messages which are Suspicious from this domain MAY be rejected, bounced, or otherwise not delivered at the option of the verifier." There is no mandate here. > I believe the IETF has not previously standardized a=20 > specification which > attempts to have one network participant dictate the internal=20 > operating > behaviors of another, outside of the protocol interaction=20 > itself. As such, > efforts in this direction need to be careful, modest and incremental. Again, there is obviously no dictation here. The ability for a sender to state a policy in such a manner that certain receivers find it most beneficial but in a way that does not constrain other receivers is a benefit, not a limitation. > 2. Unsigned vs. Mismatched Signature >=20 > The original SSP specification applied only to unsigned=20 > messages. The current > version includes mail that is signed but has different=20 > domains between the > DKIM i=3D attribute and the rfc2822.From field. Presumably,=20 > this new capability > overrides whatever reputation is associated with the message signer. >=20 > If a signer has a good reputation, then why is that not sufficient for > enabling delivery? In other words, with a signature of a=20 > domain with a good > reputation, what threats is SSP trying to protect against? Reputation systems are designed by organizations to optimize delivering good mail and stopping bad mail. They will design the reputation system however they see fit to achieve this goal. The market dynamics and innovation will define reputation systems' design, not SSP. Hypothetical statements about how reputation systems may develop aren't relevant to SSP> =20 > 6. Signature Semantics >=20 > DKIM was devised to provide a means of declaring an=20 > (organization's) identity > that is taking "responsibility" for placing a message into=20 > the transit stream. > This is a very constrained semantic for the signature, and=20 > really pertains to > no more than a delivery decision. >=20 > In reviewing the apparent semantics of full SSP use, I=20 > believe it seeks to > move a DKIM signature, which uses the same domain name as is=20 > in the From > field, into the realm of declaring content to be valid. This=20 > is a much more > demanding semantic and, I believe, moves the DKIM/SSP service=20 > into direct > competition with S/MIME and PGP. At best, this seems=20 > entirely ill-advised. > At the least, it is considerably more ambitious than the=20 > initial functions > discussed for SSP. For an initial version of a standard,=20 > more ambitious means > more risky. I have no idea what "declaring content to be valid" means. For example, I can sign a DKIM message with SSP and this DKIM message with matching i=3D and From domains can state "2+2=3D5". Certainly I'm = not validating the content here? I think you mean something else. References to S/MIME and PGP are unclear and irrelevant. I was unable to follow this thread on the list a few weeks ago. Let's determine what the requirements are and build a system to meet those requirements rather than state "this design moves into the realm of blah where blah is undefined." > DETAILED COMMENTS > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > In the absence of a valid DKIM signature on behalf of the "From" > > address [RFC2822], message verifiers implementing this=20 > specification > > MUST determine whether messages from that sender are=20 > expected to be > > signed, and what signatures are acceptable. In=20 > particular, whether a >=20 > Normative text in the Introduction? >=20 > I initially thought that the statement, here, provided a=20 > crisp statement > of scope, but then realized that the "signature on behalf of=20 > the From address" > left things unclear. >=20 > For one thing, it means that SSP will apply to some signed=20 > messages, and not > only to unsigned messages. >=20 > For another, it appears that the test to perform is with the DKIM i=3D > parameter. This can get a bit tricky. For example, since=20 > the DKIM base > specification does not require that the i=3D parameter directly=20 > relate to the > From field, this seems to carry an implied modification to=20 > DKIM base? So it > seems to require that i=3D be entirely redundant with (one of?)=20 > the rfc2822.from > address(es) in every detail? >=20 > As for "what signatures are acceptable", the implied,=20 > open-ended complexity in > this statement is huge. Think, for a moment, of just how varied the > description of 'acceptable' signatures could become. >=20 > Given that DKIM pertains to domains that are trusted, rather=20 > than to domains > that are untrusted, this line of SSP effort appears to be=20 > conflating the two > worlds. DKIM applies to both. I can determine bankofamerica.com is trusted and bankofamerica.cl is untrusted. I can use DKIM to authenticate the use of each of these domains and then apply my trusted and untrusted logic accordingly. =20 > > techniques such as DKIM is limited since unsigned messages will > > always need to be considered to be potentially legitimate. This >=20 > A declaration of the limited utility of DKIM, without SSP, is=20 > gratuitous, > probably wrong, and probably counter-productive for early=20 > DKIM adoption. I disagree. For domains which are forged regularly DKIM without SSP is limited IMHO. > > 2.9. Suspicious > >=20 > > Messages that do not contain a valid Originator=20 > Signature and which > > are inconsistent with a Sender Signing Practices check (e.g., are > > received without a Valid Signature and the sender's=20 > signing practices > > indicate all messages from the domain are signed) are=20 > referred to as > > "Suspicious". The handling of such messages is at the=20 > discretion of > > the Verifier or final recipient. "Suspicious" applies=20 > only to the > > DKIM evaluation of the message; a Verifier may decide the message > > should be accepted on the basis of other information=20 > beyond the scope > > of this document. Conversely, messages not deemed=20 > Suspicious may be >=20 > This is the strongest indication that the SSP specification=20 > has moved from > describing sender-side practices to, instead, attempting to=20 > tell receive-side > validators how to behave. Receiver-side validators are explicitly *not* being told how to behave. Their behavior is at their discretion. Some receivers may use this SSP information and it shouldn't be denied to them based on a clearly misreading of "discretion" for "dictating". I think many will use this information beneficially. > A term like "suspicious" is emotionally charged. Given that=20 > breakage can (and > will) sometimes account for the condition being described,=20 > here, it would be > better to use a term that is descriptive of the situation,=20 > rather than having > it assert a qualitative assessment. "suspicious" may be emotionally charged but "Suspicious" should not be. capitalized "Suspicious" means something very specific in the SSP document > > rejected for other reasons. >=20 > So, the term 'suspicious' will be applied to some acceptable=20 > messages and not > applied to some bogus messages? First the term "suspicious" is irrelevant. The term "Suspicious" is at play. Some acceptable messages will be "Suspicious" because they will be unsigned or have a broken signature. That's ok because the receiver can term them "Suspicious" and then, at their discretion, deem them acceptable and deliver them. Some bogus messages will have valid DKIM signatures and matching SSP policies. Such a message from an *untrustworthy* domain like bankofamerica.cl is not "Suspicious" but is bogus. =20 > > handling=3D Non-compliant message handling request for the = domain > > (plain-text; OPTIONAL). Possible values are as follows: >=20 > For some reason, the above language seems awkward to me. I=20 > assume the meaning > is "Author domain request for handling of non-compliant messages"? >=20 > In any event, this again makes clear that SSP has moved from=20 > describing > 'sender' practices into an attempt by a sender to dictate=20 > validator behaviors > when using sender practices information. Again, nothing is being dicated. The receiver has their full discretion. =20 _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzcXH-0003d6-KY; Tue, 04 Dec 2007 13:30:23 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzanC-0004Sx-Bf for apps-review-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 11:38:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzanC-0004So-1l for apps-review@ietf.org; Tue, 04 Dec 2007 11:38:42 -0500 Received: from mtcc.com ([64.142.29.208] helo=fugu.mtcc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzanA-0004MQ-43 for apps-review@ietf.org; Tue, 04 Dec 2007 11:38:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1265; t=1196786315; x=1197650315; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[ietf-dkim]=20Review=20of=20DKIM=20Send er=20Signing=20Practices=09(draft-ietf-dkim-ssp-01) |Sender:=20 |To:=20=20dcrocker@bbiw.net |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=4wyWvBQ0fK6xAec5FIdQ5Cj+JqNg8KS9BWG3EaBNJss=; b=p5F0ePQZI4op2yzX5wCARruWA7thz0HzuCgI4en0eMoV8fgrsvYenhnT1I +Tl9WhGSN3kdPgyALUvXsxV4g4scxLQsF9pafKEb7iLkH3i389u1Mt89pA86 HY0Y72odSWefSf3fwZvkTxVwrXf4QIFyjvN+V6ZTo01OQuAs26HR0=; Received: from [127.0.0.1] (fugu.mtcc.com [127.0.0.1]) (authenticated bits=0) by fugu.mtcc.com (8.14.1/8.13.8) with ESMTP id lB4GcWmO000906; Tue, 4 Dec 2007 08:38:34 -0800 Message-ID: <47558286.5040409@mtcc.com> Date: Tue, 04 Dec 2007 08:38:30 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.12) Gecko/20071019 Fedora/1.5.0.12-3.fc6 pango-text Thunderbird/1.5.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <47549320.9000307@dcrocker.net> In-Reply-To: <47549320.9000307@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: fugu.mtcc.com; v=0.1; dkim=pass, header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); ssp=pass, header.From=mike@mtcc.com X-Spam-Score: -0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Tue, 04 Dec 2007 13:30:23 -0500 Cc: DKIM IETF WG , apps-review@ietf.org Subject: [APPS-REVIEW] Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Dave Crocker wrote: > 2. Unsigned vs. Mismatched Signature > > The original SSP specification applied only to unsigned messages. The > current > version includes mail that is signed but has different domains between the > DKIM i= attribute and the rfc2822.From field. Presumably, this new > capability > overrides whatever reputation is associated with the message signer. This is hardly new. In fact, this train has long since left this station as it's in rfc5016: 5.3: 2. SSP MUST provide a concise linkage between the [RFC 2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a first party signature. Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2. I don't know why this is being brought up again after it was discussed and issue tracked for the requirements. > > If a signer has a good reputation, then why is that not sufficient for > enabling delivery? In other words, with a signature of a domain with a > good > reputation, what threats is SSP trying to protect against? SSP doesn't dictate outcome. Never has, never will. Mike _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKoa-00005Z-VE; Mon, 03 Dec 2007 18:35:05 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzKoZ-00005K-Ql for apps-review-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:35:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKoZ-00004r-Gd for apps-review@ietf.org; Mon, 03 Dec 2007 18:35:03 -0500 Received: from mail.songbird.com ([208.184.79.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzKoU-0007PG-IC for apps-review@ietf.org; Mon, 03 Dec 2007 18:35:03 -0500 Received: from [130.129.84.220] ([130.129.84.220]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB3NYTR2009273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 15:34:30 -0800 Message-ID: <47549320.9000307@dcrocker.net> Date: Mon, 03 Dec 2007 15:37:04 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: DKIM IETF WG X-Priority: 2 (High) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 (-) X-Scan-Signature: a7b3e2e89e2e73a6185808e636222e06 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Review of: DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) Reviewed by: D. Crocker 4 December 2007 The DKIM working group has followed its specification of a base method for associating a responsible identity to an email, via cryptographic signing, with the current draft, DKIM Sender Signing Practices (SSP). The SSP specification describes itself as defining a mechanism "senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results." That is, SSP permits potential DKIM signers to publish statements about how they use DKIM, and also to publish directions for DKIM validators (receivers) on how they are to handle a class of received messages. The SSP mechanism is to have a potential signer -- that is, the owner of a domain name -- publish an SSP-specific DNS TXT record, in an SSP-specific branch under the domain name. On the receive-side, the domain name under which the DNS query is made is taken from the rfc2822.From portion of an address, in a received message. By associating an organization's verifiable identity to a message, the reputation of that organization can then be used by a message receiving engine, for determining message handling, such as whether to deliver the message to the designated recipient. This is what DKIM Base permits. By contrast, SSP seeks to detect misbehaviors, specifically related to unauthorized use of a domain in an RFC2822.From field . SSP does not seek to deal with other identity fraud, such as in the RFC2822.From , the Subject field, or in the message body. In general, the draft needs to consider adoption incentives for receivers. My guess is that such an analysis will show that there is a relatively small set of publishers and receivers who are highly motivated to implement the more advanced features -- advanced relative to earlier SSP drafts -- but that true, Internet-scale adoption will be elusive for quite some time. In my opinion, the draft should be broken into an initial core, with optional extensions. The core should define the publication mechanism and the smallest set of features that are deemed useful and likely to receive a broad base of initial adoption. The extensions would target the smaller set of adopters who are viewed as being strongly motivated for these enhancement. The core would be appropriate for direct standardization, while the options would be experimental. BASIC ISSUES ============ 1. Signer/Validator practices "negotiation" scope SSP's description of itself as including "how verifiers should... interpret those results" states a scope of protocol semantics that is new to the IETF; the protocol is not constrained to "interpret" with respect to defining what the published information means, but rather is meant to guide, or even mandate, how the mail receive-side participant should handle messages. I believe the IETF has not previously standardized a specification which attempts to have one network participant dictate the internal operating behaviors of another, outside of the protocol interaction itself. As such, efforts in this direction need to be careful, modest and incremental. There have been some Internet publication mechanisms used that might be thought to be similar to SSP. Most are third-party, centrally controlled attribute or quality databases. These are an entirely different administrative and information models from the self-published directive nature of SSP. 2. Unsigned vs. Mismatched Signature The original SSP specification applied only to unsigned messages. The current version includes mail that is signed but has different domains between the DKIM i= attribute and the rfc2822.From field. Presumably, this new capability overrides whatever reputation is associated with the message signer. If a signer has a good reputation, then why is that not sufficient for enabling delivery? In other words, with a signature of a domain with a good reputation, what threats is SSP trying to protect against? 3. Scope and scale of query traffic SSP originally was constrained to apply only to unsigned mail. The current specification applies to unsigned messages *and* signed messages where the DKIM i= domain name does not match the rfc2822.From domain. This is a considerable change in the nature -- and potentially a considerable change in the amount of query traffic -- that SSP causes. The draft does note that initial receive-side adopters of SSP will find no SSP DNS record. However the draft does not address the adoption and use impact of being expected to make a query that will almost always fail for a significant number of years into the future. 4. Service Model Although bits of Service Model description are in the document -- mostly the Introduction -- the specification lacks a coherent description of its operating framework and, instead, dives directly into normative detail, often without providing an integrated view of the service. 5. DKIM-Signature d= vs. i= parameter use Recent discussions about using DKIM Base have uncovered some confusion about the semantics and role for the values of the d= and i= signature parameters. In particular, which of them specifies the single identity that is the validated "output" of a DKIM receive-side signature processor, as representing the signer's declaration of a responsible identity? From my reading of extended conversations on this issue, it is not yet resolved. In looking at the way this issue is discussed, my best guess is that it will not be resolved merely by discussion. That is, I think it will require a few years of operational practice before the question is settled. The current SSP specification chooses to use the i= parameter. At best this ensures that that portion of SSP should be considered as experimental. At worst, it is actually the wrong choice. 6. Signature Semantics DKIM was devised to provide a means of declaring an (organization's) identity that is taking "responsibility" for placing a message into the transit stream. This is a very constrained semantic for the signature, and really pertains to no more than a delivery decision. In reviewing the apparent semantics of full SSP use, I believe it seeks to move a DKIM signature, which uses the same domain name as is in the From field, into the realm of declaring content to be valid. This is a much more demanding semantic and, I believe, moves the DKIM/SSP service into direct competition with S/MIME and PGP. At best, this seems entirely ill-advised. At the least, it is considerably more ambitious than the initial functions discussed for SSP. For an initial version of a standard, more ambitious means more risky. 7. Resolution in the Face of Multiple From field Addresses When there are multiple address in a message's rfc2822.From field, the SSP specification arbitrarily declares that the first address shall be used for SSP enforcement. Although multiple From addresses is rare, its use is valid and, in particular, occurs when the content's authors want to communicate something significant about the authorship. In light of that, arbitrarily coercing which of the authors is allowed to submit the message is quite troubling, especially since it is usually a subordinate author who does the scut work of document maintenance and public posting. Unfortunately, this is a problem for which there is no obvious solution. Since SSP should not get into the business of changing who is permitted to post valid mail, the issue does very much need better resolution. 8. Filter Engine vs. End-user as SSP Target Human Factors ("usability") design is an arcane topic largely resolved only by experimentation. Certainly effective design of user interfaces is a black art. As a consequence, the IETF has made it a practice to avoid the topic entirely. This issue came up repeatedly during the early -- and later -- days of DKIM and was resolved by deciding that DKIM's target is the receive-side delivery filtering engine, rather than the human recipient. The current SSP has re-introduced a range of assumptions about use with human recipients, and has used those assumptions for dictating specification details. The specification needs to remove all consideration of human issues or else to provide substantial empirical basis for its inclusion. 9. Threat Analysis I believe the current specification pursues a narrow range of threats, without there being a clear statement of what those threats are, and why they need resolution, when other threats do not. Given the previous work on threats, pertaining to DKIM (and SSP?) this could well be a simple exercise. I am raising the issue, because I suspect that the current work goes beyond what was previously analyzed. DETAILED COMMENTS ================= > Abstract > > 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 > > > > Allman, et al. Expires March 20, 2008 [Page 1] > > Internet-Draft DKIM SSP September 2007 > > > [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. "...access and interpret those results." What "results"? As for "interpreting", a basic question is whether the publisher of SSP records is simply stating their own behavior or whether they are providing direction to receivers. Language like "how verifiers should interpret those results" does not have to mean the latter, but it comes close and does appear to be what is intended, as one reads the rest of the document. > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 > 2.1. Terms Imported from DKIM Signatures Specification . . . . 5 > 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 > 2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5 > 2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6 > 2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6 > 2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6 > 2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6 > 2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6 > 2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6 > 2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7 > 2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7 > 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7 > 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8 > 4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9 > 4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10 > 4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 > 6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14 > 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 > 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 > Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 > B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15 > B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 > B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16 > B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 > Intellectual Property and Copyright Statements . . . . . . . . . . 18 > > > > > > > > > > > > > > > > Allman, et al. Expires March 20, 2008 [Page 3] > > Internet-Draft DKIM SSP September 2007 > > > 1. Introduction > > DomainKeys Identified Mail (DKIM) defines a mechanism by which email > messages can be cryptographically signed, permitting a signing domain > to claim responsibility for the introduction of a message into the > mail stream. Message recipients can verify the signature by querying > the signer's domain directly to retrieve the appropriate public key, > and thereby confirm that the message was attested to by a party in > possession of the private key for the signing domain. > > However, the legacy of the Internet is such that not all messages > will be signed, and the absence of a signature on a message is not an > a priori indication of forgery. In fact, during early phases of > deployment it must be expected that most messages will remain > unsigned. However, some domains may choose to sign all of their > outgoing mail, for example, to protect their brand name. It is > highly desirable for such domains to be able to advertise that fact > to verifiers, and that messages claiming to be from them that do not > have a valid signature are likely to be forgeries. This is the topic > for sender signing practices. This seems to ignore the potential for broken signatures, which produces "unsigned" messages that are not forgeries. Still, the above paragraph provides a very clean statement of scope: "some domains may choose to sign all of their outgoing mail, for example, to protect their brand name. It is highly desirable for such domains to be able to advertise that fact to verifiers" The paragraph would help readers by distinguishing this bit of text visually and by holding the issue of forgery for a separate -- and better qualified -- commentary. > In the absence of a valid DKIM signature on behalf of the "From" > address [RFC2822], message verifiers implementing this specification > MUST determine whether messages from that sender are expected to be > signed, and what signatures are acceptable. In particular, whether a Normative text in the Introduction? I initially thought that the statement, here, provided a crisp statement of scope, but then realized that the "signature on behalf of the From address" left things unclear. For one thing, it means that SSP will apply to some signed messages, and not only to unsigned messages. For another, it appears that the test to perform is with the DKIM i= parameter. This can get a bit tricky. For example, since the DKIM base specification does not require that the i= parameter directly relate to the From field, this seems to carry an implied modification to DKIM base? So it seems to require that i= be entirely redundant with (one of?) the rfc2822.from address(es) in every detail? As for "what signatures are acceptable", the implied, open-ended complexity in this statement is huge. Think, for a moment, of just how varied the description of 'acceptable' signatures could become. Given that DKIM pertains to domains that are trusted, rather than to domains that are untrusted, this line of SSP effort appears to be conflating the two worlds. > domain signs all outbound email must be made available to the > verifier. Without such a mechanism, the benefit of message signing Here is the normative "must" again. In any event, what does this must sentence mean? > techniques such as DKIM is limited since unsigned messages will > always need to be considered to be potentially legitimate. This A declaration of the limited utility of DKIM, without SSP, is gratuitous, probably wrong, and probably counter-productive for early DKIM adoption. > determination is referred to as a Sender Signing Practices check. > > Conceivably, such expressions might be imagined to be extended in the > future to include information about what hashing algorithms a domain > uses, what kind of messages might be sent (e.g., bulk vs. personal > vs. transactional), etc. Such concerns are out of scope of this Conceivably, such expressions might be imagined to be extended to do just about anything... What is the purpose of adding this kind of hypothetical here? Whatever the intent, it actually serves to distract the focus of the current specification, by invoking issues that are entirely out of scope for a specification. It needs to be removed. > standard, because they can be expressed in the key record > ("Selector") with which the signature is verified. In contrast, this This appears to be raising the issue of what to publish via one kind of record, versus another (and probably versus within the message.) That's a useful conceptual design topic, but probably best dealt with on its own, rather than as a secondary aspect of a hypothetical. > specification focuses on information which is relevant in the absence > of a valid signature. Expressions of signing practice which require > outside auditing are similarly out of scope for this specification > because they fall under the purview of reputation and accreditation. What does "outside auditing" mean, here? > The detailed requirements for Sender Signing Practices are given in > [I-D.ietf-dkim-ssp-requirements], which the protocol described in > this document attempts to satisfy. This document refers extensively > to [RFC4871], which should be read as a prerequisite to this > document. > > > > > Allman, et al. Expires March 20, 2008 [Page 4] > > Internet-Draft DKIM SSP September 2007 > > > 2. Language and Terminology > > 2.1. Terms Imported from DKIM Signatures Specification > > Some terminology used herein is derived directly from [RFC4871]. > Briefly, > > o A "Signer" is the agent that signs a message. In many cases it > will correspond closely with the original author of the message or > an agent working on the author's behalf. Why not simply say that it is the domain listed in the d= parameter of a DKIM signature? Looking at the definition of d= and the definition of i=, it appears that d= is the signer. > o A "Verifier" is the agent that verifies a message by checking the > actual signature against the message itself and the public key > published by the Alleged Signer. The Verifier also looks up the > Sender Signing Practices published by the domain of the Originator > Address if the message is not correctly signed by the Alleged > Originator. Again: SSP is now not restricted to unsigned messages. It applies also to a potentially very large class of signed messages. In effect, SSP now appears to attempting to emulate SPF strictures of correlation among identity fields. Question: Is DKIM for transit validation or is it for content authentication? If the latter, then it truly has become competitive with S/MIME and PGP? If the former, then why does SSP need to attempt such rigorous enforcement of From field details? > o A "Selector" specifies which of the keys published by a signing > domain should be queried. It is essentially a way of subdividing > the address space to allow a single sending domain to publish > multiple keys. > > 2.2. Valid Signature > > A "Valid Signature" is any signature on a message which correctly > verifies using the procedure described in section 6.1 of [RFC4871]. > > 2.3. Originator Address > > The "Originator Address" is the email address in the From header > field of a message [RFC2822], or if and only if the From header field > contains multiple addresses, the first address in the From header > field. This means "Author", since RFC2822 uses the term Originator more broadly and it does not seem advisable to have SSP define the term differently. (FWIW, the email-arch draft is being changed to say 'author', also.) > NON-NORMATIVE RATIONALE: The alternative option when there are > multiple addresses in the From header field is to use the value of > the Sender header field. This would be closer to the semantics > indicated in [RFC2822] than using the first address in the From > header field. However, the large number of deployed Mail User > Agents that do not display the Sender header field value argues > against that. Multiple addresses in the From header field are > rare in real life. Actually, the problem here is that the definition is a bit Procrustean and effectively modifies RFC2821 and/or RFC2822, since it constrains who is permitted to be listed as an author (or the order in which they can be listed) and still post the message. The document needs a single address here, so that having a From that lists multiple actual authors is inconvenient. While it might or might not be practical to arbitrarily choose the first author address, it is nonetheless quite arbitrary. And arbitrary choices in situations like this suggest shaky ground for the basic mechanism. At the least, it suggests that the scope of application for the mechanism is limited. The limitation should simply be stated, rather than hacked around. The reference to display of addresses discloses a basic assumption in the SSP work, namely that it pertains to what is displayed to users. This is vastly different than determining deliverability of a message and, again, suggests that SSP is attempting to declare the validity of particular content. In any event, since SSP is declaring a choice on the basis of what is displayed to users, where is the empirical basis for knowing that it will have the desired effect? By the way, where is that desired effect stated in this document? > Even when there is only one address in the From header field, this > address is chosen as the reference address for SSP lookups because > it represents the author of the message and is more widely > displayed by Mail User Agents as a result. The Sender header > > > > Allman, et al. Expires March 20, 2008 [Page 5] > > Internet-Draft DKIM SSP September 2007 > > > field frequently has other meanings. I'm not at all sure what precise "meanings" SSP is seeking, here, nor what other "meanings" a Sender field can have. Please clarify. > 2.4. Originator Domain > > The "Originator Domain" is everything to the right of the "@" in the > Originator Address (excluding the "@" itself). > > 2.5. Alleged Signer > > An "Alleged Signer" is the identity of the signer claimed in a DKIM- > Signature header field in a message received by a Verifier; it is > "alleged" because it has not yet been verified. d= parameter? > 2.6. Alleged Originator > > An "Alleged Originator" is the Originator Address of a message > received by a Verifier; it is "alleged" because it has not yet been > verified. SSP is stating that it verifies the From field? > 2.7. Sender Signing Practices > > "Sender Signing Practices" (or just "practices") consist of a > machine-readable record published by the domain of the Alleged > Originator which includes information about whether or not that > domain signs all of their email, and whether signatures from third > parties are sanctioned by the Alleged Originator. > > 2.8. Originator Signature > > An "Originator Signature" is any Valid Signature where the signing > address (listed in the "i=" tag if present, otherwise its default > value, consisting of the null address, representing an unknown user, > followed by "@", followed by the value of the "d=" tag) matches the > Originator Address. If the signing address does not include a local- > part, then only the domains must match; otherwise, the two addresses > must be identical. Hmmm... i=... There is significant confusion about the semantics of d= vs. i=. Having SSP make normative choices that rely on a particular resolution of that issue, before there is significant field experience to establish the semantics the operational world will use, is quite risky. > 2.9. Suspicious > > Messages that do not contain a valid Originator Signature and which > are inconsistent with a Sender Signing Practices check (e.g., are > received without a Valid Signature and the sender's signing practices > indicate all messages from the domain are signed) are referred to as > "Suspicious". The handling of such messages is at the discretion of > the Verifier or final recipient. "Suspicious" applies only to the > DKIM evaluation of the message; a Verifier may decide the message > should be accepted on the basis of other information beyond the scope > of this document. Conversely, messages not deemed Suspicious may be This is the strongest indication that the SSP specification has moved from describing sender-side practices to, instead, attempting to tell receive-side validators how to behave. A term like "suspicious" is emotionally charged. Given that breakage can (and will) sometimes account for the condition being described, here, it would be better to use a term that is descriptive of the situation, rather than having it assert a qualitative assessment. > Allman, et al. Expires March 20, 2008 [Page 6] > > Internet-Draft DKIM SSP September 2007 > > > rejected for other reasons. So, the term 'suspicious' will be applied to some acceptable messages and not applied to some bogus messages? > 2.10. Third-Party Signature > > A "Third-Party Signature" is a Valid Signature which is not an > Originator Signature. So everyone who handles a message, but is not the author, and signs it with their own domain, is a third-party? This reinforces the suggestion that a more neutral and precise term be used, rather than 'suspicious'. Starting from the assumption that all "third party" signatures are "suspicious" is misguided, since it is already likely that operators will be signing with their own domain, even when the rfc2822 From is for one of their customer's organizations. > 2.11. Verifier Acceptable Third-Party Signature > > A Verifier Acceptable Third-Party Signature is a Third-Party > Signature that the Verifier is willing to accept as meaningful for > the message under consideration. The Verifier may use any criteria > it deems appropriate for making this determination. While it might seem an arbitrary criterion to use for this assessment, the length of the term, here, should serve to suggest that its domain of discourse is far beyond anything that should be covered in a first-attempt for a new mechanism like this. At the least, it mandates a fairly thorough discussion of the signer/validator decision model into which it fits. In other words, the label makes clear that this is a complex realm, yet we have no description of it in terms of likely publishers and likely users of the published information. > 3. Operation Overview > > Sender Signing Practices checks MUST be based on the Originator > Address. If the message contains a valid Originator Signature, no > Sender Signing Practices check need be performed: the Verifier Exactly. The original SSP was invoked when there was no signature. The current SSP is invoked when the i= domain is not the same as the rfc2822.from domain. Very different model. > SHOULD NOT look up the Sender Signing Practices and the message MUST > NOT be considered Suspicious. > > Verifiers checking messages that do not have at least one valid > Originator Signature MUST perform a Sender Signing Practices check on > the domain specified by the Originator Address as described in > Section 4.4. > > A Sender Signing Practices check produces one of four possible > results: > > 1. Some messages from this domain are not signed; the message MUST > NOT be considered Suspicious, even in the absence of a valid > signature. This is the default. Which is the same as we get when there is no SSP. So why is it needed? > 2. All messages from this domain are signed. Messages containing a > Verifier Acceptable Third-Party Signature MUST NOT be considered > Suspicious. > > NON-NORMATIVE RATIONALE: Third-party signatures, since they > can potentially represent any domain, are considered more > likely to be abused by attackers seeking to spoof a specific A third-party signature of a domain that has a good reputation is more likely to represent spoofing??? This sounds like the enforcement of the Author domain on signing overrides any reputation that might exist for the signer. Is that really what is intended? > address. It may therefore be desirable for verifiers to apply > other criteria outside the scope of this specification in > deciding to accept a given third-party signature. For The sentence really gets to the core problem: Verifiers already use a vast array of criteria and they have made clear they are going to continue to do so. Yet SSP seems to be written with the belief that it can force changes to that array, rather than merely making a friendly effort to add to the repertoire of information that validators might choose to use. Note that the specification is written so as to incur added query overhead for nearly every message, even though, for virtually all initial occurrences, the query will fail. What is the basis for believing that validators are willing to incur this overhead? > example, a list of known mailing list domains used by > addresses served by the verifier might be specifically > considered acceptable third-party signers. One of the problems with path-based registration is that it requires registering mailing list servers. It appears that the above text is attempting to impose that limitation on DKIM signing. > Allman, et al. Expires March 20, 2008 [Page 7] > > Internet-Draft DKIM SSP September 2007 > > > 3. All valid messages from this domain are signed; the domain of the > Alleged Originator requests that only messages with valid > Originator Signatures be considered not Suspicious; Third-Party > Signatures are irrelevant. This practice would typically be used "irrelevant"? In any event, what is the basis for believing that there will be substantial adoption of this feature by validators? > by domains which send only transactional email (i.e., do not use > mailing lists and such that are likely to break signatures) and > which wish to emphasize security over deliverability of their > messages. In the absence of a valid Originator Signature, the > message MUST be considered Suspicious. > > 4. The domain does not exist; the message MUST be considered > Suspicious. Presumably "does not exist" means there is no DNS record. (Otherwise, the phrase "does not exist" needs to be explained.) Since virtually all initial queries will find that there is no DNS record, this mandates treating virtually all mail as "suspicious" for some unknown number of years/decades. So what, exactly, is the behavior of a validator that is being specified, for a message to be "suspicious"? For that matter, what does it mean for a message NOT to be "suspicious"? > If the Sender Signing Practices record for the domain does not exist > but the domain does exist, Verifier systems MUST assume that some > messages from this domain are not signed and the message MUST NOT be > considered Suspicious. I think the above text should be labeled #5, since it specifies a condition different from #4? > 4. Detailed Description > > 4.1. DNS Representation > > Sender Signing Practices records are published using the DNS TXT > resource record type. > > NON-NORMATIVE DISCUSSION: There has been considerable discussion > on the DKIM WG mailing list regarding the relative advantages of > TXT and a new resource record (RR) type. 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. > However, without a "flag day" on which SSP TXT record support is > to be withdrawn, such support is likely to continue indefinitely. > As a result, this specification defines no new RR type for SSP. > > Another alternative proposed by P. Hallam-Baker is the publication > of both a TXT record and, when implementations permit, a new RR, > referred to as XPTR, which gives the location from which SSP and > other policy information relating to a give domain can be > retrieved. This has the advantage of supporting a variety of > policies in a scalable manner, with better handling of wildcards > and centralized publication of policy records, with caching > advantages. However, the above implementation issues also apply > to XPTR, and an additional lookup is required to retrieve SSP via > the XPTR method. At the time of publication of this draft, > consensus on this proposal was unclear. > > > > > Allman, et al. Expires March 20, 2008 [Page 8] > > Internet-Draft DKIM SSP September 2007 > > > The RDATA for SSP resource records is textual in format, with > specific syntax and semantics relating to their role in describing > sender signing practices. The "Tag=Value List" syntax described in > section 3.2 of [RFC4871] is used. Records not in compliance with > that syntax or the syntax of individual tags described in Section 4.3 > MUST be ignored (considered equivalent to a NODATA result) for > purposes of message disposition, although they MAY cause the logging > of warning messages via an appropriate system logging mechanism. > > SSP records for a domain are published at a location in the domain's > DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for > example.com would be a TXT record that is published at > _ssp._domainkey.example.com. While the sub-naming scheme is reasonable, why not merely have _ssp by itself, as _ssp.example.com rather than _ssp._domainkey? The two-level approach makes sense if there is any reasonable expectation of very large numbers of underscore-delimited attribute space. Otherwise is seems like unnecessary overhead. My own guess is that scaling is not an issue here. > 4.2. Publication of SSP Records > > Sender Signing Practices are intended to apply to all mail sent from "Intended"? In terms of what is specified, what does this mean? > the domain of an Alleged Originator, and to the greatest extent > possible, to all subdomains of that domain. There are several cases > that need to be considered in that regard: > > o The domain itself > > o Subdomains which may or may not be used for email > > o Hostnames which may or may not be used for email > > o Other named resource records in the domain > > o Multi-level examples of the above, e.g., a.b.example.com > > o Non-existent cases, i.e., a subdomain or hostname that does not > actually exist within the domain By "not actually exist" I assume this refers to not being visible in the public DNS? Is public visibility the proper constraint for defining whether a domain name exists? > Normally, a domain expressing Sender Signing Practices will want to > do so for both itself and all of its "descendents" (child domains and > hosts, at all lower levels). Domains wishing to do so MUST publish > SSP records as follows: > > Publish an SSP record for the domain itself > > Publish an SSP record for any existing subdomain > > Note that since the lookup algorithm described below references the > immediate parent of the alleged originating domain, it is not > necessary to publish SSP records for every single-level label within > the domain. This has been done to relieve domain administrators of > the burden of publishing an SSP record for every other record in the > > > > Allman, et al. Expires March 20, 2008 [Page 9] > > Internet-Draft DKIM SSP September 2007 > > > domain, which would be otherwise required. > > Wildcards within a domain, including but not limited to wildcard MX > records, pose a particular problem. While referencing the immediate > parent domain allows the discovery of an SSP record corresponding to > an unintended immediate-child subdomain, wildcard records apply at > multiple levels. For example, if there is a wildcard MX record for > example.com, the domain foo.bar.example.com can receive mail through > the named mail exchanger. Conversely, the existence of the record > makes it impossible to tell whether foo.bar.example.com is a > legitimate name since a query for that name will not return an > NXDOMAIN error. For that reason, SSP coverage for subdomains of > domains containing a wildcard record is incomplete. > > NON-NORMATIVE NOTE: Complete SSP coverage of domains containing > (or where any parent contains) wildcards generally cannot be > guaranteed. > > 4.3. Record Syntax > > SSP records follow the "tag=value" syntax described in section 3.2 of > [RFC4871]. The SSP record syntax is a tag-list as defined in that > section, including the restriction on duplicate tags, the use of > white space, and case sensitivity. > > Tags used in SSP records are as follows. Unrecognized tags MUST be > ignored. In the ABNF below, the FWS token is inherited from > [RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens > are imported from [RFC4234]. > > dkim= Outbound signing practices for the domain (plain-text; > REQUIRED). Possible values are as follows: > > unknown The domain may sign some or all email. > > all All mail from the domain is signed; unsigned email MUST be > considered Suspicious. The domain may send messages through > agents that may modify and re-sign messages, so email signed > with a Verifier Acceptable Third-Party Signature SHOULD NOT be > considered Suspicious. I believe that "from the domain" is not rigorously defined in the specification. I believe the definition being used here is that the domain in the DKIM-Signature i= parameter must match the domain in the rfc2822.From field. > strict All mail from the domain is signed; messages lacking a > valid Originator Signature MUST be considered Suspicious. The > domain does not expect to send messages through agents that may > modify and re-sign messages. This value appears to conflate three separate issues: 1. All mail with this domain in the From field will be signed by that domain. 2. No mail with this domain in the From field will be sent via mailing lists or other Mediators (re-posting services.) 3. The owner of this domain considers non-delivery (including due to broken signature) preferable over delivery of messages with this domain in the From field, but lacking a valid signature with this domain in the i= parameter. At a minimum, the document should have text that considers the range of mail practices, such that this particular configuration of behaviors and needs is only one of the set. That way, there is a serious context for assessing the choice to have this particular, single flag, as representing a particular multi-attribute set. In terms of terminology choice, a more semantically useful label might be something like "integrated". Many scenarios could be "strict", so that the choice, here, does not convey much specific meaning. I suggest "integrated" because I believe the flag applies to scenarios in which all aspects of the sender's email content and operations are tightly integrated. > Allman, et al. Expires March 20, 2008 [Page 10] > > Internet-Draft DKIM SSP September 2007 > > > NON-NORMATIVE RATIONALE: Strict practices may be used by > entities which send only transactional email to individual > addresses and which are willing to accept the consequence of > having some mail which is re-signed appear suspicious in > return for additional control over their addresses. Strict > practices may also be used by entities which do not send > (and therefore do not sign) any email. > > ABNF: > > ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" / > "all" / "strict") To repeat: Even if not specified into the set of parameter values, it would be useful to have some text that explores the space of choices that these 3 values are chosen from. > handling= Non-compliant message handling request for the domain > (plain-text; OPTIONAL). Possible values are as follows: For some reason, the above language seems awkward to me. I assume the meaning is "Author domain request for handling of non-compliant messages"? In any event, this again makes clear that SSP has moved from describing 'sender' practices into an attempt by a sender to dictate validator behaviors when using sender practices information. > process Messages which are Suspicious from this domain SHOULD be > processed by the verifier, although the SSP failure MAY be > considered in subsequent evaluation of the message. This is > the default value. > > deny Messages which are Suspicious from this domain MAY be > rejected, bounced, or otherwise not delivered at the option of > the verifier. > > NON-NORMATIVE EXPLANATION: The "deny" practice is intended > for use by domains that value security over deliverability. > For example, a domain used by a financial institution to > send transactional email, which signs all of its messages, > might consider their concern about phishing messages > purporting to come from their domain to be higher than their > concern about some some legitimate messages not being > delivered. The "handling=deny" practice allows them to > express that concern in a way that can be acted upon by > verifiers, if they so choose. > > ABNF: > > ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" / > "deny") > > t= Flags, represented as a colon-separated list of names (plain-text; > OPTIONAL, default is that no flags are set). Flag values are: > > y The domain is testing signing practices, and the Verifier > SHOULD NOT consider a message suspicious based on the record. I'll again make the long-standing observation that a "testing" bit permanently burdens implementations with a mechanism that is useful only in the early stages of the protocol. Again note that such a mechanism has not been needed for previous Internet protocols. > Allman, et al. Expires March 20, 2008 [Page 11] > > Internet-Draft DKIM SSP September 2007 > > > s The signing practices apply only to the named domain, and not > to subdomains. So this is intended to overcome the problem of not being able to use wildcards? What is the query behavior that validators need to use, to discover this record, when they start with a message having a deeply-nested From field domain name? > ABNF: > > ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag > 0*( [FWS] ":" [FWS] ssp-t-tag-flag ) > ssp-t-tag-flag = "y" / "s" / hyphenated-word > ; for future extension > hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") > (ALPHA / DIGIT) ] > > Unrecognized flags MUST be ignored. > > 4.4. Sender Signing Practices Check Procedure > > Verifiers MUST produce a result that is semantically equivalent to > applying the following steps in the order listed. In practice, > several of these steps can be performed in parallel in order to > improve performance. > > 1. If a valid Originator Signature exists, the message is not > Suspicious, and the algorithm terminates. > > 2. The Verifier MUST query DNS for a TXT record corresponding to > the Originator Domain prefixed by "_ssp._domainkey.". If the > result of this query is a NOERROR response with one or more > answers which are syntactically-valid SSP responses, proceed to > step 7. > > 3. The Verifier MUST query DNS for an MX record corresponding to > the Originator Domain (with no prefix). This query is made only > to check the existence of the domain name and MAY be done in > parallel with the query made in step 2. If the result of this > query is an NXDOMAIN error, the message is Suspicious and the > algorithm terminates. This seems to make clear that SSP has moved seriously into more general aspects of receive-side analysis. At best, this is premature for this work. > NON-NORMATIVE DISCUSSION: Any resource record type could be > used for this query since the existence of a resource record > of any type will prevent an NXDOMAIN error. The choice of MX > for this purpose is because this record type is thought to be > the most common for likely domains, and will therefore result > in a result which can be more readily cached than a negative > result. > > 4. If the immediate parent of the Originator Domain is a top-level > domain (a domain consisting of a single element such as "com", > "us", or "jp"), then the message is not Suspicious (because no > > > > Allman, et al. Expires March 20, 2008 [Page 12] > > Internet-Draft DKIM SSP September 2007 > > > SSP record was found) and the algorithm terminates. The > verifier MAY also compare the parent domain against a locally- > maintained list of known address suffixes (e.g., .co.uk) and > terminate the algorithm with a not Suspicious result if the > parent domain matches an entry on the list. Specifying anything that attempts to use knowledge of domain name hierarchy conventions is particularly ill-advised. > 5. The Verifier MUST query DNS for a TXT record for the immediate > parent domain, prefixed with "_ssp._domainkey." If the result > of this query is a NOERROR response with one or more answers > which are syntactically-valid SSP responses, proceed to step 6. > Otherwise, the message is not Suspicious and the algorithm > terminates. > > 6. If the SSP "t" tag exists in the response and any of the flags > is "s" (indicating it should not apply to a subdomain), the > message is not Suspicious and the algorithm terminates. > > 7. If the SSP "t" tag exists in the response and any of the flags > is "y" (indicating testing), the message is not Suspicious and > the algorithm terminates. > > 8. If the value of the SSP "dkim" tag is "unknown", the message is > not Suspicious and the algorithm terminates. > > 9. If the value of the SSP "dkim" tag is "all", and one or more > Verifier Acceptable Third-Party Signatures are present on the > message, the message is not Suspicious and the algorithm > terminates. > > 10. The message is Suspicious and the algorithm terminates. > > If any of the queries involved in the Sender Signing Practices Check > result in a SERVFAIL error response, the verifier MAY either queue > the message or return an SMTP error indicating a temporary failure. This is a fairly complex decision tree, for an initial specification of a new type of protocol. > 5. IANA Considerations > > IANA is requested to create a "DKIM selector name" registry and to > reserve the selector name "_ssp" to avoid confusion between DKIM key > records and SSP records. > > > 6. Security Considerations > > Security considerations in the Sender Signing Practices are mostly > related to attempts on the part of malicious senders to represent > themselves as other senders, often in an attempt to defraud either > > > > Allman, et al. Expires March 20, 2008 [Page 13] > > Internet-Draft DKIM SSP September 2007 > > > the recipient or the Alleged Originator. > > Additional security considerations regarding Sender Signing Practices > may be found in the DKIM threat analysis [RFC4686]. My guess is that the security issues for this specification are quite substantial and that there needs to be quite a bit more effort to consider them. > 6.1. Fraudulent Sender Address > > [[Assuming 3rd party signature is based on Sender header field]] If > the Sender Signing Practices sanction third-party signing, an > attacker can create a message with a From header field of an > arbitrary sender and a legitimately signed Sender header field > > 6.2. DNS Attacks > > An attacker might attack the DNS infrastructure in an attempt to > impersonate SSP records. However, such an attacker is more likely to > attack at a higher level, e.g., redirecting A or MX record lookups in > order to capture traffic that was legitimately intended for the > target domain. Domains concerned about this should use DNSSEC > [RFC4033]. > > Because SSP operates within the framework of the legacy e-mail > system, the default result in the absence of an SSP record is that > the domain does not sign all of its messages. Therefore, a DNS > attack which is successful in suppressing the SSP response to the > verifier is sufficient to cause the verifier to see unsigned messages > as non-suspicious, even when that is not intended by the alleged > originating domain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKQo-0005qt-OT; Mon, 03 Dec 2007 18:10:30 -0500 Received: from apps-review by megatron.ietf.org with local (Exim 4.43) id 1IzKQn-0005qh-Fy for apps-review-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:10:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKQh-0005ge-4Y for apps-review@ietf.org; Mon, 03 Dec 2007 18:10:23 -0500 Received: from mail.songbird.com ([208.184.79.10]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzKQc-0007AW-9b for apps-review@ietf.org; Mon, 03 Dec 2007 18:10:23 -0500 Received: from [130.129.84.220] ([130.129.84.220]) (authenticated bits=0) by mail.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id lB3N9n2b003356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 15:09:53 -0800 Message-ID: <47548D58.4060200@dcrocker.net> Date: Mon, 03 Dec 2007 15:12:24 -0800 From: Dave Crocker Organization: Brandenburg InternetWorking User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: DKIM IETF WG X-Priority: 2 (High) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7b3e2e89e2e73a6185808e636222e06 Cc: apps-review@ietf.org Subject: [APPS-REVIEW] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) X-BeenThere: apps-review@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Applications Review List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: apps-review-bounces@ietf.org Review of: DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01) Reviewed by: D. Crocker 4 December 2007 The DKIM working group has followed its specification of a base method for associating a responsible identity to an email, via cryptographic signing, with the current draft, DKIM Sender Signing Practices (SSP). The SSP specification describes itself as defining a mechanism "senders may use to advertise how they sign their outgoing mail, and how verifiers should access and interpret those results." That is, SSP permits potential DKIM signers to publish statements about how they use DKIM, and also to publish directions for DKIM validators (receivers) on how they are to handle a class of received messages. The SSP mechanism is to have a potential signer -- that is, the owner of a domain name -- publish an SSP-specific DNS TXT record, in an SSP-specific branch under the domain name. On the receive-side, the domain name under which the DNS query is made is taken from the rfc2822.From portion of an address, in a received message. By associating an organization's verifiable identity to a message, the reputation of that organization can then be used by a message receiving engine, for determining message handling, such as whether to deliver the message to the designated recipient. This is what DKIM Base permits. By contrast, SSP seeks to detect misbehaviors, specifically related to unauthorized use of a domain in an RFC2822.From field . SSP does not seek to deal with other identity fraud, such as in the RFC2822.From , the Subject field, or in the message body. In general, the draft needs to consider adoption incentives for receivers. My guess is that such an analysis will show that there is a relatively small set of publishers and receivers who are highly motivated to implement the more advanced features -- advanced relative to earlier SSP drafts -- but that true, Internet-scale adoption will be elusive for quite some time. In my opinion, the draft should be broken into an initial core, with optional extensions. The core should define the publication mechanism and the smallest set of features that are deemed useful and likely to receive a broad base of initial adoption. The extensions would target the smaller set of adopters who are viewed as being strongly motivated for these enhancement. The core would be appropriate for direct standardization, while the options would be experimental. BASIC ISSUES ============ 1. Signer/Validator practices "negotiation" scope SSP's description of itself as including "how verifiers should... interpret those results" states a scope of protocol semantics that is new to the IETF; the protocol is not constrained to "interpret" with respect to defining what the published information means, but rather is meant to guide, or even mandate, how the mail receive-side participant should handle messages. I believe the IETF has not previously standardized a specification which attempts to have one network participant dictate the internal operating behaviors of another, outside of the protocol interaction itself. As such, efforts in this direction need to be careful, modest and incremental. There have been some Internet publication mechanisms used that might be thought to be similar to SSP. Most are third-party, centrally controlled attribute or quality databases. These are an entirely different administrative and information models from the self-published directive nature of SSP. 2. Unsigned vs. Mismatched Signature The original SSP specification applied only to unsigned messages. The current version includes mail that is signed but has different domains between the DKIM i= attribute and the rfc2822.From field. Presumably, this new capability overrides whatever reputation is associated with the message signer. If a signer has a good reputation, then why is that not sufficient for enabling delivery? In other words, with a signature of a domain with a good reputation, what threats is SSP trying to protect against? 3. Scope and scale of query traffic SSP originally was constrained to apply only to unsigned mail. The current specification applies to unsigned messages *and* signed messages where the DKIM i= domain name does not match the rfc2822.From domain. This is a considerable change in the nature -- and potentially a considerable change in the amount of query traffic -- that SSP causes. The draft does note that initial receive-side adopters of SSP will find no SSP DNS record. However the draft does not address the adoption and use impact of being expected to make a query that will almost always fail for a significant number of years into the future. 4. Service Model Although bits of Service Model description are in the document -- mostly the Introduction -- the specification lacks a coherent description of its operating framework and, instead, dives directly into normative detail, often without providing an integrated view of the service. 5. DKIM-Signature d= vs. i= parameter use Recent discussions about using DKIM Base have uncovered some confusion about the semantics and role for the values of the d= and i= signature parameters. In particular, which of them specifies the single identity that is the validated "output" of a DKIM receive-side signature processor, as representing the signer's declaration of a responsible identity? From my reading of extended conversations on this issue, it is not yet resolved. In looking at the way this issue is discussed, my best guess is that it will not be resolved merely by discussion. That is, I think it will require a few years of operational practice before the question is settled. The current SSP specification chooses to use the i= parameter. At best this ensures that that portion of SSP should be considered as experimental. At worst, it is actually the wrong choice. 6. Signature Semantics DKIM was devised to provide a means of declaring an (organization's) identity that is taking "responsibility" for placing a message into the transit stream. This is a very constrained semantic for the signature, and really pertains to no more than a delivery decision. In reviewing the apparent semantics of full SSP use, I believe it seeks to move a DKIM signature, which uses the same domain name as is in the From field, into the realm of declaring content to be valid. This is a much more demanding semantic and, I believe, moves the DKIM/SSP service into direct competition with S/MIME and PGP. At best, this seems entirely ill-advised. At the least, it is considerably more ambitious than the initial functions discussed for SSP. For an initial version of a standard, more ambitious means more risky. 7. Resolution in the Face of Multiple From field Addresses When there are multiple address in a message's rfc2822.From field, the SSP specification arbitrarily declares that the first address shall be used for SSP enforcement. Although multiple From addresses is rare, its use is valid and, in particular, occurs when the content's authors want to communicate something significant about the authorship. In light of that, arbitrarily coercing which of the authors is allowed to submit the message is quite troubling, especially since it is usually a subordinate author who does the scut work of document maintenance and public posting. Unfortunately, this is a problem for which there is no obvious solution. Since SSP should not get into the business of changing who is permitted to post valid mail, the issue does very much need better resolution. 8. Filter Engine vs. End-user as SSP Target Human Factors ("usability") design is an arcane topic largely resolved only by experimentation. Certainly effective design of user interfaces is a black art. As a consequence, the IETF has made it a practice to avoid the topic entirely. This issue came up repeatedly during the early -- and later -- days of DKIM and was resolved by deciding that DKIM's target is the receive-side delivery filtering engine, rather than the human recipient. The current SSP has re-introduced a range of assumptions about use with human recipients, and has used those assumptions for dictating specification details. The specification needs to remove all consideration of human issues or else to provide substantial empirical basis for its inclusion. 9. Threat Analysis I believe the current specification pursues a narrow range of threats, without there being a clear statement of what those threats are, and why they need resolution, when other threats do not. Given the previous work on threats, pertaining to DKIM (and SSP?) this could well be a simple exercise. I am raising the issue, because I suspect that the current work goes beyond what was previously analyzed. DETAILED COMMENTS ================= > Abstract > > 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 > > > > Allman, et al. Expires March 20, 2008 [Page 1] > > Internet-Draft DKIM SSP September 2007 > > > [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. "...access and interpret those results." What "results"? As for "interpreting", a basic question is whether the publisher of SSP records is simply stating their own behavior or whether they are providing direction to receivers. Language like "how verifiers should interpret those results" does not have to mean the latter, but it comes close and does appear to be what is intended, as one reads the rest of the document. > Table of Contents > > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 5 > 2.1. Terms Imported from DKIM Signatures Specification . . . . 5 > 2.2. Valid Signature . . . . . . . . . . . . . . . . . . . . . 5 > 2.3. Originator Address . . . . . . . . . . . . . . . . . . . . 5 > 2.4. Originator Domain . . . . . . . . . . . . . . . . . . . . 6 > 2.5. Alleged Signer . . . . . . . . . . . . . . . . . . . . . . 6 > 2.6. Alleged Originator . . . . . . . . . . . . . . . . . . . . 6 > 2.7. Sender Signing Practices . . . . . . . . . . . . . . . . . 6 > 2.8. Originator Signature . . . . . . . . . . . . . . . . . . . 6 > 2.9. Suspicious . . . . . . . . . . . . . . . . . . . . . . . . 6 > 2.10. Third-Party Signature . . . . . . . . . . . . . . . . . . 7 > 2.11. Verifier Acceptable Third-Party Signature . . . . . . . . 7 > 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 7 > 4. Detailed Description . . . . . . . . . . . . . . . . . . . . . 8 > 4.1. DNS Representation . . . . . . . . . . . . . . . . . . . . 8 > 4.2. Publication of SSP Records . . . . . . . . . . . . . . . . 9 > 4.3. Record Syntax . . . . . . . . . . . . . . . . . . . . . . 10 > 4.4. Sender Signing Practices Check Procedure . . . . . . . . . 12 > 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 > 6.1. Fraudulent Sender Address . . . . . . . . . . . . . . . . 14 > 6.2. DNS Attacks . . . . . . . . . . . . . . . . . . . . . . . 14 > 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 > 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 > 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 > Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 > Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 15 > B.1. Changes since -ietf-dkim-ssp-00 . . . . . . . . . . . . . 15 > B.2. Changes since -allman-ssp-02 . . . . . . . . . . . . . . . 16 > B.3. Changes since -allman-ssp-01 . . . . . . . . . . . . . . . 16 > B.4. Changes since -allman-ssp-00 . . . . . . . . . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 > Intellectual Property and Copyright Statements . . . . . . . . . . 18 > > > > > > > > > > > > > > > > Allman, et al. Expires March 20, 2008 [Page 3] > > Internet-Draft DKIM SSP September 2007 > > > 1. Introduction > > DomainKeys Identified Mail (DKIM) defines a mechanism by which email > messages can be cryptographically signed, permitting a signing domain > to claim responsibility for the introduction of a message into the > mail stream. Message recipients can verify the signature by querying > the signer's domain directly to retrieve the appropriate public key, > and thereby confirm that the message was attested to by a party in > possession of the private key for the signing domain. > > However, the legacy of the Internet is such that not all messages > will be signed, and the absence of a signature on a message is not an > a priori indication of forgery. In fact, during early phases of > deployment it must be expected that most messages will remain > unsigned. However, some domains may choose to sign all of their > outgoing mail, for example, to protect their brand name. It is > highly desirable for such domains to be able to advertise that fact > to verifiers, and that messages claiming to be from them that do not > have a valid signature are likely to be forgeries. This is the topic > for sender signing practices. This seems to ignore the potential for broken signatures, which produces "unsigned" messages that are not forgeries. Still, the above paragraph provides a very clean statement of scope: "some domains may choose to sign all of their outgoing mail, for example, to protect their brand name. It is highly desirable for such domains to be able to advertise that fact to verifiers" The paragraph would help readers by distinguishing this bit of text visually and by holding the issue of forgery for a separate -- and better qualified -- commentary. > In the absence of a valid DKIM signature on behalf of the "From" > address [RFC2822], message verifiers implementing this specification > MUST determine whether messages from that sender are expected to be > signed, and what signatures are acceptable. In particular, whether a Normative text in the Introduction? I initially thought that the statement, here, provided a crisp statement of scope, but then realized that the "signature on behalf of the From address" left things unclear. For one thing, it means that SSP will apply to some signed messages, and not only to unsigned messages. For another, it appears that the test to perform is with the DKIM i= parameter. This can get a bit tricky. For example, since the DKIM base specification does not require that the i= parameter directly relate to the From field, this seems to carry an implied modification to DKIM base? So it seems to require that i= be entirely redundant with (one of?) the rfc2822.from address(es) in every detail? As for "what signatures are acceptable", the implied, open-ended complexity in this statement is huge. Think, for a moment, of just how varied the description of 'acceptable' signatures could become. Given that DKIM pertains to domains that are trusted, rather than to domains that are untrusted, this line of SSP effort appears to be conflating the two worlds. > domain signs all outbound email must be made available to the > verifier. Without such a mechanism, the benefit of message signing Here is the normative "must" again. In any event, what does this must sentence mean? > techniques such as DKIM is limited since unsigned messages will > always need to be considered to be potentially legitimate. This A declaration of the limited utility of DKIM, without SSP, is gratuitous, probably wrong, and probably counter-productive for early DKIM adoption. > determination is referred to as a Sender Signing Practices check. > > Conceivably, such expressions might be imagined to be extended in the > future to include information about what hashing algorithms a domain > uses, what kind of messages might be sent (e.g., bulk vs. personal > vs. transactional), etc. Such concerns are out of scope of this Conceivably, such expressions might be imagined to be extended to do just about anything... What is the purpose of adding this kind of hypothetical here? Whatever the intent, it actually serves to distract the focus of the current specification, by invoking issues that are entirely out of scope for a specification. It needs to be removed. > standard, because they can be expressed in the key record > ("Selector") with which the signature is verified. In contrast, this This appears to be raising the issue of what to publish via one kind of record, versus another (and probably versus within the message.) That's a useful conceptual design topic, but probably best dealt with on its own, rather than as a secondary aspect of a hypothetical. > specification focuses on information which is relevant in the absence > of a valid signature. Expressions of signing practice which require > outside auditing are similarly out of scope for this specification > because they fall under the purview of reputation and accreditation. What does "outside auditing" mean, here? > The detailed requirements for Sender Signing Practices are given in > [I-D.ietf-dkim-ssp-requirements], which the protocol described in > this document attempts to satisfy. This document refers extensively > to [RFC4871], which should be read as a prerequisite to this > document. > > > > > Allman, et al. Expires March 20, 2008 [Page 4] > > Internet-Draft DKIM SSP September 2007 > > > 2. Language and Terminology > > 2.1. Terms Imported from DKIM Signatures Specification > > Some terminology used herein is derived directly from [RFC4871]. > Briefly, > > o A "Signer" is the agent that signs a message. In many cases it > will correspond closely with the original author of the message or > an agent working on the author's behalf. Why not simply say that it is the domain listed in the d= parameter of a DKIM signature? Looking at the definition of d= and the definition of i=, it appears that d= is the signer. > o A "Verifier" is the agent that verifies a message by checking the > actual signature against the message itself and the public key > published by the Alleged Signer. The Verifier also looks up the > Sender Signing Practices published by the domain of the Originator > Address if the message is not correctly signed by the Alleged > Originator. Again: SSP is now not restricted to unsigned messages. It applies also to a potentially very large class of signed messages. In effect, SSP now appears to attempting to emulate SPF strictures of correlation among identity fields. Question: Is DKIM for transit validation or is it for content authentication? If the latter, then it truly has become competitive with S/MIME and PGP? If the former, then why does SSP need to attempt such rigorous enforcement of From field details? > o A "Selector" specifies which of the keys published by a signing > domain should be queried. It is essentially a way of subdividing > the address space to allow a single sending domain to publish > multiple keys. > > 2.2. Valid Signature > > A "Valid Signature" is any signature on a message which correctly > verifies using the procedure described in section 6.1 of [RFC4871]. > > 2.3. Originator Address > > The "Originator Address" is the email address in the From header > field of a message [RFC2822], or if and only if the From header field > contains multiple addresses, the first address in the From header > field. This means "Author", since RFC2822 uses the term Originator more broadly and it does not seem advisable to have SSP define the term differently. (FWIW, the email-arch draft is being changed to say 'author', also.) > NON-NORMATIVE RATIONALE: The alternative option when there are > multiple addresses in the From header field is to use the value of > the Sender header field. This would be closer to the semantics > indicated in [RFC2822] than using the first address in the From > header field. However, the large number of deployed Mail User > Agents that do not display the Sender header field value argues > against that. Multiple addresses in the From header field are > rare in real life. Actually, the problem here is that the definition is a bit Procrustean and effectively modifies RFC2821 and/or RFC2822, since it constrains who is permitted to be listed as an author (or the order in which they can be listed) and still post the message. The document needs a single address here, so that having a From that lists multiple actual authors is inconvenient. While it might or might not be practical to arbitrarily choose the first author address, it is nonetheless quite arbitrary. And arbitrary choices in situations like this suggest shaky ground for the basic mechanism. At the least, it suggests that the scope of application for the mechanism is limited. The limitation should simply be stated, rather than hacked around. The reference to display of addresses discloses a basic assumption in the SSP work, namely that it pertains to what is displayed to users. This is vastly different than determining deliverability of a message and, again, suggests that SSP is attempting to declare the validity of particular content. In any event, since SSP is declaring a choice on the basis of what is displayed to users, where is the empirical basis for knowing that it will have the desired effect? By the way, where is that desired effect stated in this document? > Even when there is only one address in the From header field, this > address is chosen as the reference address for SSP lookups because > it represents the author of the message and is more widely > displayed by Mail User Agents as a result. The Sender header > > > > Allman, et al. Expires March 20, 2008 [Page 5] > > Internet-Draft DKIM SSP September 2007 > > > field frequently has other meanings. I'm not at all sure what precise "meanings" SSP is seeking, here, nor what other "meanings" a Sender field can have. Please clarify. > 2.4. Originator Domain > > The "Originator Domain" is everything to the right of the "@" in the > Originator Address (excluding the "@" itself). > > 2.5. Alleged Signer > > An "Alleged Signer" is the identity of the signer claimed in a DKIM- > Signature header field in a message received by a Verifier; it is > "alleged" because it has not yet been verified. d= parameter? > 2.6. Alleged Originator > > An "Alleged Originator" is the Originator Address of a message > received by a Verifier; it is "alleged" because it has not yet been > verified. SSP is stating that it verifies the From field? > 2.7. Sender Signing Practices > > "Sender Signing Practices" (or just "practices") consist of a > machine-readable record published by the domain of the Alleged > Originator which includes information about whether or not that > domain signs all of their email, and whether signatures from third > parties are sanctioned by the Alleged Originator. > > 2.8. Originator Signature > > An "Originator Signature" is any Valid Signature where the signing > address (listed in the "i=" tag if present, otherwise its default > value, consisting of the null address, representing an unknown user, > followed by "@", followed by the value of the "d=" tag) matches the > Originator Address. If the signing address does not include a local- > part, then only the domains must match; otherwise, the two addresses > must be identical. Hmmm... i=... There is significant confusion about the semantics of d= vs. i=. Having SSP make normative choices that rely on a particular resolution of that issue, before there is significant field experience to establish the semantics the operational world will use, is quite risky. > 2.9. Suspicious > > Messages that do not contain a valid Originator Signature and which > are inconsistent with a Sender Signing Practices check (e.g., are > received without a Valid Signature and the sender's signing practices > indicate all messages from the domain are signed) are referred to as > "Suspicious". The handling of such messages is at the discretion of > the Verifier or final recipient. "Suspicious" applies only to the > DKIM evaluation of the message; a Verifier may decide the message > should be accepted on the basis of other information beyond the scope > of this document. Conversely, messages not deemed Suspicious may be This is the strongest indication that the SSP specification has moved from describing sender-side practices to, instead, attempting to tell receive-side validators how to behave. A term like "suspicious" is emotionally charged. Given that breakage can (and will) sometimes account for the condition being described, here, it would be better to use a term that is descriptive of the situation, rather than having it assert a qualitative assessment. > Allman, et al. Expires March 20, 2008 [Page 6] > > Internet-Draft DKIM SSP September 2007 > > > rejected for other reasons. So, the term 'suspicious' will be applied to some acceptable messages and not applied to some bogus messages? > 2.10. Third-Party Signature > > A "Third-Party Signature" is a Valid Signature which is not an > Originator Signature. So everyone who handles a message, but is not the author, and signs it with their own domain, is a third-party? This reinforces the suggestion that a more neutral and precise term be used, rather than 'suspicious'. Starting from the assumption that all "third party" signatures are "suspicious" is misguided, since it is already likely that operators will be signing with their own domain, even when the rfc2822 From is for one of their customer's organizations. > 2.11. Verifier Acceptable Third-Party Signature > > A Verifier Acceptable Third-Party Signature is a Third-Party > Signature that the Verifier is willing to accept as meaningful for > the message under consideration. The Verifier may use any criteria > it deems appropriate for making this determination. While it might seem an arbitrary criterion to use for this assessment, the length of the term, here, should serve to suggest that its domain of discourse is far beyond anything that should be covered in a first-attempt for a new mechanism like this. At the least, it mandates a fairly thorough discussion of the signer/validator decision model into which it fits. In other words, the label makes clear that this is a complex realm, yet we have no description of it in terms of likely publishers and likely users of the published information. > 3. Operation Overview > > Sender Signing Practices checks MUST be based on the Originator > Address. If the message contains a valid Originator Signature, no > Sender Signing Practices check need be performed: the Verifier Exactly. The original SSP was invoked when there was no signature. The current SSP is invoked when the i= domain is not the same as the rfc2822.from domain. Very different model. > SHOULD NOT look up the Sender Signing Practices and the message MUST > NOT be considered Suspicious. > > Verifiers checking messages that do not have at least one valid > Originator Signature MUST perform a Sender Signing Practices check on > the domain specified by the Originator Address as described in > Section 4.4. > > A Sender Signing Practices check produces one of four possible > results: > > 1. Some messages from this domain are not signed; the message MUST > NOT be considered Suspicious, even in the absence of a valid > signature. This is the default. Which is the same as we get when there is no SSP. So why is it needed? > 2. All messages from this domain are signed. Messages containing a > Verifier Acceptable Third-Party Signature MUST NOT be considered > Suspicious. > > NON-NORMATIVE RATIONALE: Third-party signatures, since they > can potentially represent any domain, are considered more > likely to be abused by attackers seeking to spoof a specific A third-party signature of a domain that has a good reputation is more likely to represent spoofing??? This sounds like the enforcement of the Author domain on signing overrides any reputation that might exist for the signer. Is that really what is intended? > address. It may therefore be desirable for verifiers to apply > other criteria outside the scope of this specification in > deciding to accept a given third-party signature. For The sentence really gets to the core problem: Verifiers already use a vast array of criteria and they have made clear they are going to continue to do so. Yet SSP seems to be written with the belief that it can force changes to that array, rather than merely making a friendly effort to add to the repertoire of information that validators might choose to use. Note that the specification is written so as to incur added query overhead for nearly every message, even though, for virtually all initial occurrences, the query will fail. What is the basis for believing that validators are willing to incur this overhead? > example, a list of known mailing list domains used by > addresses served by the verifier might be specifically > considered acceptable third-party signers. One of the problems with path-based registration is that it requires registering mailing list servers. It appears that the above text is attempting to impose that limitation on DKIM signing. > Allman, et al. Expires March 20, 2008 [Page 7] > > Internet-Draft DKIM SSP September 2007 > > > 3. All valid messages from this domain are signed; the domain of the > Alleged Originator requests that only messages with valid > Originator Signatures be considered not Suspicious; Third-Party > Signatures are irrelevant. This practice would typically be used "irrelevant"? In any event, what is the basis for believing that there will be substantial adoption of this feature by validators? > by domains which send only transactional email (i.e., do not use > mailing lists and such that are likely to break signatures) and > which wish to emphasize security over deliverability of their > messages. In the absence of a valid Originator Signature, the > message MUST be considered Suspicious. > > 4. The domain does not exist; the message MUST be considered > Suspicious. Presumably "does not exist" means there is no DNS record. (Otherwise, the phrase "does not exist" needs to be explained.) Since virtually all initial queries will find that there is no DNS record, this mandates treating virtually all mail as "suspicious" for some unknown number of years/decades. So what, exactly, is the behavior of a validator that is being specified, for a message to be "suspicious"? For that matter, what does it mean for a message NOT to be "suspicious"? > If the Sender Signing Practices record for the domain does not exist > but the domain does exist, Verifier systems MUST assume that some > messages from this domain are not signed and the message MUST NOT be > considered Suspicious. I think the above text should be labeled #5, since it specifies a condition different from #4? > 4. Detailed Description > > 4.1. DNS Representation > > Sender Signing Practices records are published using the DNS TXT > resource record type. > > NON-NORMATIVE DISCUSSION: There has been considerable discussion > on the DKIM WG mailing list regarding the relative advantages of > TXT and a new resource record (RR) type. 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. > However, without a "flag day" on which SSP TXT record support is > to be withdrawn, such support is likely to continue indefinitely. > As a result, this specification defines no new RR type for SSP. > > Another alternative proposed by P. Hallam-Baker is the publication > of both a TXT record and, when implementations permit, a new RR, > referred to as XPTR, which gives the location from which SSP and > other policy information relating to a give domain can be > retrieved. This has the advantage of supporting a variety of > policies in a scalable manner, with better handling of wildcards > and centralized publication of policy records, with caching > advantages. However, the above implementation issues also apply > to XPTR, and an additional lookup is required to retrieve SSP via > the XPTR method. At the time of publication of this draft, > consensus on this proposal was unclear. > > > > > Allman, et al. Expires March 20, 2008 [Page 8] > > Internet-Draft DKIM SSP September 2007 > > > The RDATA for SSP resource records is textual in format, with > specific syntax and semantics relating to their role in describing > sender signing practices. The "Tag=Value List" syntax described in > section 3.2 of [RFC4871] is used. Records not in compliance with > that syntax or the syntax of individual tags described in Section 4.3 > MUST be ignored (considered equivalent to a NODATA result) for > purposes of message disposition, although they MAY cause the logging > of warning messages via an appropriate system logging mechanism. > > SSP records for a domain are published at a location in the domain's > DNS hierarchy prefixed by _ssp._domainkey; e.g., the SSP record for > example.com would be a TXT record that is published at > _ssp._domainkey.example.com. While the sub-naming scheme is reasonable, why not merely have _ssp by itself, as _ssp.example.com rather than _ssp._domainkey? The two-level approach makes sense if there is any reasonable expectation of very large numbers of underscore-delimited attribute space. Otherwise is seems like unnecessary overhead. My own guess is that scaling is not an issue here. > 4.2. Publication of SSP Records > > Sender Signing Practices are intended to apply to all mail sent from "Intended"? In terms of what is specified, what does this mean? > the domain of an Alleged Originator, and to the greatest extent > possible, to all subdomains of that domain. There are several cases > that need to be considered in that regard: > > o The domain itself > > o Subdomains which may or may not be used for email > > o Hostnames which may or may not be used for email > > o Other named resource records in the domain > > o Multi-level examples of the above, e.g., a.b.example.com > > o Non-existent cases, i.e., a subdomain or hostname that does not > actually exist within the domain By "not actually exist" I assume this refers to not being visible in the public DNS? Is public visibility the proper constraint for defining whether a domain name exists? > Normally, a domain expressing Sender Signing Practices will want to > do so for both itself and all of its "descendents" (child domains and > hosts, at all lower levels). Domains wishing to do so MUST publish > SSP records as follows: > > Publish an SSP record for the domain itself > > Publish an SSP record for any existing subdomain > > Note that since the lookup algorithm described below references the > immediate parent of the alleged originating domain, it is not > necessary to publish SSP records for every single-level label within > the domain. This has been done to relieve domain administrators of > the burden of publishing an SSP record for every other record in the > > > > Allman, et al. Expires March 20, 2008 [Page 9] > > Internet-Draft DKIM SSP September 2007 > > > domain, which would be otherwise required. > > Wildcards within a domain, including but not limited to wildcard MX > records, pose a particular problem. While referencing the immediate > parent domain allows the discovery of an SSP record corresponding to > an unintended immediate-child subdomain, wildcard records apply at > multiple levels. For example, if there is a wildcard MX record for > example.com, the domain foo.bar.example.com can receive mail through > the named mail exchanger. Conversely, the existence of the record > makes it impossible to tell whether foo.bar.example.com is a > legitimate name since a query for that name will not return an > NXDOMAIN error. For that reason, SSP coverage for subdomains of > domains containing a wildcard record is incomplete. > > NON-NORMATIVE NOTE: Complete SSP coverage of domains containing > (or where any parent contains) wildcards generally cannot be > guaranteed. > > 4.3. Record Syntax > > SSP records follow the "tag=value" syntax described in section 3.2 of > [RFC4871]. The SSP record syntax is a tag-list as defined in that > section, including the restriction on duplicate tags, the use of > white space, and case sensitivity. > > Tags used in SSP records are as follows. Unrecognized tags MUST be > ignored. In the ABNF below, the FWS token is inherited from > [RFC2822] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens > are imported from [RFC4234]. > > dkim= Outbound signing practices for the domain (plain-text; > REQUIRED). Possible values are as follows: > > unknown The domain may sign some or all email. > > all All mail from the domain is signed; unsigned email MUST be > considered Suspicious. The domain may send messages through > agents that may modify and re-sign messages, so email signed > with a Verifier Acceptable Third-Party Signature SHOULD NOT be > considered Suspicious. I believe that "from the domain" is not rigorously defined in the specification. I believe the definition being used here is that the domain in the DKIM-Signature i= parameter must match the domain in the rfc2822.From field. > strict All mail from the domain is signed; messages lacking a > valid Originator Signature MUST be considered Suspicious. The > domain does not expect to send messages through agents that may > modify and re-sign messages. This value appears to conflate three separate issues: 1. All mail with this domain in the From field will be signed by that domain. 2. No mail with this domain in the From field will be sent via mailing lists or other Mediators (re-posting services.) 3. The owner of this domain considers non-delivery (including due to broken signature) preferable over delivery of messages with this domain in the From field, but lacking a valid signature with this domain in the i= parameter. At a minimum, the document should have text that considers the range of mail practices, such that this particular configuration of behaviors and needs is only one of the set. That way, there is a serious context for assessing the choice to have this particular, single flag, as representing a particular multi-attribute set. In terms of terminology choice, a more semantically useful label might be something like "integrated". Many scenarios could be "strict", so that the choice, here, does not convey much specific meaning. I suggest "integrated" because I believe the flag applies to scenarios in which all aspects of the sender's email content and operations are tightly integrated. > Allman, et al. Expires March 20, 2008 [Page 10] > > Internet-Draft DKIM SSP September 2007 > > > NON-NORMATIVE RATIONALE: Strict practices may be used by > entities which send only transactional email to individual > addresses and which are willing to accept the consequence of > having some mail which is re-signed appear suspicious in > return for additional control over their addresses. Strict > practices may also be used by entities which do not send > (and therefore do not sign) any email. > > ABNF: > > ssp-dkim-tag = "dkim" [FWS] "=" [FWS] ("unknown" / > "all" / "strict") To repeat: Even if not specified into the set of parameter values, it would be useful to have some text that explores the space of choices that these 3 values are chosen from. > handling= Non-compliant message handling request for the domain > (plain-text; OPTIONAL). Possible values are as follows: For some reason, the above language seems awkward to me. I assume the meaning is "Author domain request for handling of non-compliant messages"? In any event, this again makes clear that SSP has moved from describing 'sender' practices into an attempt by a sender to dictate validator behaviors when using sender practices information. > process Messages which are Suspicious from this domain SHOULD be > processed by the verifier, although the SSP failure MAY be > considered in subsequent evaluation of the message. This is > the default value. > > deny Messages which are Suspicious from this domain MAY be > rejected, bounced, or otherwise not delivered at the option of > the verifier. > > NON-NORMATIVE EXPLANATION: The "deny" practice is intended > for use by domains that value security over deliverability. > For example, a domain used by a financial institution to > send transactional email, which signs all of its messages, > might consider their concern about phishing messages > purporting to come from their domain to be higher than their > concern about some some legitimate messages not being > delivered. The "handling=deny" practice allows them to > express that concern in a way that can be acted upon by > verifiers, if they so choose. > > ABNF: > > ssp-handling-tag = "handling" [FWS] "=" [FWS] ("process" / > "deny") > > t= Flags, represented as a colon-separated list of names (plain-text; > OPTIONAL, default is that no flags are set). Flag values are: > > y The domain is testing signing practices, and the Verifier > SHOULD NOT consider a message suspicious based on the record. I'll again make the long-standing observation that a "testing" bit permanently burdens implementations with a mechanism that is useful only in the early stages of the protocol. Again note that such a mechanism has not been needed for previous Internet protocols. > Allman, et al. Expires March 20, 2008 [Page 11] > > Internet-Draft DKIM SSP September 2007 > > > s The signing practices apply only to the named domain, and not > to subdomains. So this is intended to overcome the problem of not being able to use wildcards? What is the query behavior that validators need to use, to discover this record, when they start with a message having a deeply-nested From field domain name? > ABNF: > > ssp-t-tag = %x75 [FWS] "=" [FWS] ssp-t-tag-flag > 0*( [FWS] ":" [FWS] ssp-t-tag-flag ) > ssp-t-tag-flag = "y" / "s" / hyphenated-word > ; for future extension > hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") > (ALPHA / DIGIT) ] > > Unrecognized flags MUST be ignored. > > 4.4. Sender Signing Practices Check Procedure > > Verifiers MUST produce a result that is semantically equivalent to > applying the following steps in the order listed. In practice, > several of these steps can be performed in parallel in order to > improve performance. > > 1. If a valid Originator Signature exists, the message is not > Suspicious, and the algorithm terminates. > > 2. The Verifier MUST query DNS for a TXT record corresponding to > the Originator Domain prefixed by "_ssp._domainkey.". If the > result of this query is a NOERROR response with one or more > answers which are syntactically-valid SSP responses, proceed to > step 7. > > 3. The Verifier MUST query DNS for an MX record corresponding to > the Originator Domain (with no prefix). This query is made only > to check the existence of the domain name and MAY be done in > parallel with the query made in step 2. If the result of this > query is an NXDOMAIN error, the message is Suspicious and the > algorithm terminates. This seems to make clear that SSP has moved seriously into more general aspects of receive-side analysis. At best, this is premature for this work. > NON-NORMATIVE DISCUSSION: Any resource record type could be > used for this query since the existence of a resource record > of any type will prevent an NXDOMAIN error. The choice of MX > for this purpose is because this record type is thought to be > the most common for likely domains, and will therefore result > in a result which can be more readily cached than a negative > result. > > 4. If the immediate parent of the Originator Domain is a top-level > domain (a domain consisting of a single element such as "com", > "us", or "jp"), then the message is not Suspicious (because no > > > > Allman, et al. Expires March 20, 2008 [Page 12] > > Internet-Draft DKIM SSP September 2007 > > > SSP record was found) and the algorithm terminates. The > verifier MAY also compare the parent domain against a locally- > maintained list of known address suffixes (e.g., .co.uk) and > terminate the algorithm with a not Suspicious result if the > parent domain matches an entry on the list. Specifying anything that attempts to use knowledge of domain name hierarchy conventions is particularly ill-advised. > 5. The Verifier MUST query DNS for a TXT record for the immediate > parent domain, prefixed with "_ssp._domainkey." If the result > of this query is a NOERROR response with one or more answers > which are syntactically-valid SSP responses, proceed to step 6. > Otherwise, the message is not Suspicious and the algorithm > terminates. > > 6. If the SSP "t" tag exists in the response and any of the flags > is "s" (indicating it should not apply to a subdomain), the > message is not Suspicious and the algorithm terminates. > > 7. If the SSP "t" tag exists in the response and any of the flags > is "y" (indicating testing), the message is not Suspicious and > the algorithm terminates. > > 8. If the value of the SSP "dkim" tag is "unknown", the message is > not Suspicious and the algorithm terminates. > > 9. If the value of the SSP "dkim" tag is "all", and one or more > Verifier Acceptable Third-Party Signatures are present on the > message, the message is not Suspicious and the algorithm > terminates. > > 10. The message is Suspicious and the algorithm terminates. > > If any of the queries involved in the Sender Signing Practices Check > result in a SERVFAIL error response, the verifier MAY either queue > the message or return an SMTP error indicating a temporary failure. This is a fairly complex decision tree, for an initial specification of a new type of protocol. > 5. IANA Considerations > > IANA is requested to create a "DKIM selector name" registry and to > reserve the selector name "_ssp" to avoid confusion between DKIM key > records and SSP records. > > > 6. Security Considerations > > Security considerations in the Sender Signing Practices are mostly > related to attempts on the part of malicious senders to represent > themselves as other senders, often in an attempt to defraud either > > > > Allman, et al. Expires March 20, 2008 [Page 13] > > Internet-Draft DKIM SSP September 2007 > > > the recipient or the Alleged Originator. > > Additional security considerations regarding Sender Signing Practices > may be found in the DKIM threat analysis [RFC4686]. My guess is that the security issues for this specification are quite substantial and that there needs to be quite a bit more effort to consider them. > 6.1. Fraudulent Sender Address > > [[Assuming 3rd party signature is based on Sender header field]] If > the Sender Signing Practices sanction third-party signing, an > attacker can create a message with a From header field of an > arbitrary sender and a legitimately signed Sender header field > > 6.2. DNS Attacks > > An attacker might attack the DNS infrastructure in an attempt to > impersonate SSP records. However, such an attacker is more likely to > attack at a higher level, e.g., redirecting A or MX record lookups in > order to capture traffic that was legitimately intended for the > target domain. Domains concerned about this should use DNSSEC > [RFC4033]. > > Because SSP operates within the framework of the legacy e-mail > system, the default result in the absence of an SSP record is that > the domain does not sign all of its messages. Therefore, a DNS > attack which is successful in suppressing the SSP response to the > verifier is sufficient to cause the verifier to see unsigned messages > as non-suspicious, even when that is not intended by the alleged > originating domain. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ APPS-REVIEW mailing list APPS-REVIEW@ietf.org https://www1.ietf.org/mailman/listinfo/apps-review