From johnl@iecc.com Wed Sep 1 03:02:20 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E6B3A6956 for ; Wed, 1 Sep 2010 03:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.167 X-Spam-Level: X-Spam-Status: No, score=-109.167 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_05=-1.11, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phjEgUkfKldr for ; Wed, 1 Sep 2010 03:02:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D2EE83A6958 for ; Wed, 1 Sep 2010 03:02:16 -0700 (PDT) Received: (qmail 88081 invoked from network); 1 Sep 2010 10:02:47 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 1 Sep 2010 10:02:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1009; olt=johnl@user.iecc.com; bh=5nkxNNkAx6vxSRJlm5cA6Ad08ofxeHXfQaZZrI+WISo=; b=iS7ukYcUmosOEnaAPu+/6snQoXZObQe1KiNHekBLpLkybfkqg7l99huaJn0ws/BRnkyh+f8zSKG/x3r/aX1F0wRzshXtC8EYGmWrsWVqt2FSeFWcaF+93tkF4+6MaCddr4c+sTDcnMH/G9PKlMHypYHZgOMnjZVVH+D6U2lIKTA= Date: 1 Sep 2010 10:02:45 -0000 Message-ID: <20100901100245.17034.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 10:02:20 -0000 >> (minor detail) I believe John was the first one to propose the split >between small and large domains/queries. I was passing on a summary of what we discussed at DAC. >Oops, sorry. If the Internet were a crime scene John would be in >trouble, his prints are all over it. :-) Gee, you're a fine one to talk. >In a nutshell: I'm trying to decouple the definition of what you're >asserting from the mechanism by which you assert it. -- Nathaniel In the large model, I think that makes sense since it's likely that different dossiers, even from the same provider, will have different sets of data. The idea of the small model was to have something simple and locked down, so it was straightforward to interoperate. Needless to say, the more options you have, the harder it is to interoperate, and the last thing you want is something that in theory has a zillion options, but the undocumented reality is that nobody supports more than two of them. R's, John From vesely@tana.it Wed Sep 1 04:26:07 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA2233A67D4 for ; Wed, 1 Sep 2010 04:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.172 X-Spam-Level: X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja0S1VySSGqj for ; Wed, 1 Sep 2010 04:26:06 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id D9E333A679F for ; Wed, 1 Sep 2010 04:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1283340392; bh=vKAof9YlxSH2TX68Tk1q2P0nGrPJqKLr2Waw5y3XIhE=; l=3795; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OhrlvkaBIcZJfuk9DrRm+NYC8M5jkX0ksu0PhqwKyGDLiYhXiibdD+FQ/BzzD8jPm llnVLMnbnE7olCLXidCrNiyx/+wYfcaYH7dFJ3Fi4fPaGZLGc9gj4OUoSZMgx4AvFl BSlKSvSmmnicyCODow+NGTUaR00dp5Thwmh/bHyI= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 01 Sep 2010 13:26:32 +0200 id 00000000005DC035.000000004C7E3868.00005ABB Message-ID: <4C7E3868.5050306@tana.it> Date: Wed, 01 Sep 2010 13:26:32 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C779114.3050109@tana.it> <4C7D84BF.5060101@mail-abuse.org> <201008311905.47118.ietf-dkim@kitterman.com> In-Reply-To: <201008311905.47118.ietf-dkim@kitterman.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 11:26:07 -0000 On 01/Sep/10 01:05, Scott Kitterman wrote: > On Tuesday, August 31, 2010 06:39:59 pm Douglas Otis wrote: >> Signing a message using DKIM MUST NOT be considered "taking >> responsibility" for actions of subsequent MTAs. After all, use of >> subsequent MTAs permit destinations to be modified, and messages >> replayed. These actions are well beyond the control of the signing >> domain. This is particularly true for public mailing lists. DKIM alone does not allow to distinguish malicious replaying from normal expansion or forwarding. >> Reasons for using DKIM is largely to guard against spoofing the >> source of a message. In the course of doing my job, I might send >> samples of messages used to entice victims to my colleagues, who then >> take the needed precautions. However, if such a message were to become >> replayed and widely distributed, who would be acting irresponsibly? The >> entity initially sending the message, or those granted access to a >> subsequent MTA that allows destinations to be modified, and then >> replayed to large numbers of unskilled recipients? IMHO, both, even if the latter is more guilty. If the signed message was in a public mailing list, anyone could play the replaying, which is a reason for not signing messages to MLMs (but /this/ is off topic here.) >> Large domains might rate-limit accounts to protect their systems from >> being associated with bulk unsolicited email. A bad-actor could >> establish a new account and then send themselves messages of which they >> intent to replay well beyond reason. Once the large domain discovers >> the abuse, they will be unable to stop the campaign. Why should the >> large domain offering low cost accounts be held accountable for abuse >> they can not be expected to control? Because it accepted a questionable user. > So I guess we should just give up on DKIM since it's useless as an input for > reputation for anything else? "Incomplete" and "useless" are rather different... > In any case, this is off topic here, since assessing the reputation > of domain is up to a reputation provider and not something we can > standardize. Which reputation provider? I don't think we can reasonably expect that someone will reliably synthesize reputation data for each domain on the Earth. First, they must have some input in order to do that. Second, there must be a good number of them, since the number of domains is huge. In order to standardize how such data is exchanged, we are better off knowing how the overall architecture is modeled. The concept of "cooperative domain" is crucial here, as in FBL management. Why would honest domains cooperate in order to abate spam? As in the prisoner's dilemma [WP], they currently defect. However, given some infrastructure that allows their behavior to be monitored, they'd be better off cooperating. (Social networks sometimes exemplify how to induce cooperative behavior. For simulations see e.g. "Cooperation through communication: Agent-based models and experimental results" [DT].) In case we are clever enough to work out a model that suits our needs, we'll be able to standardize all the required data exchanges. Nathaniel has identified five documents in the last sentence of [NB]. In case we are lazy, we should at least avoid to standardize something that precludes building a cooperative reputation system. For example, we should provide for a flexible way of resolving who is the reputation tracker for a given domain. -- [WP] http://en.wikipedia.org/wiki/Prisoner%27s_Dilemma [DT] http://paduaresearch.cab.unipd.it/1910/ [NB] http://www.ietf.org/mail-archive/web/domainrep/current/msg00229.html From ietf-dkim@kitterman.com Wed Sep 1 04:52:30 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C8163A68D4 for ; Wed, 1 Sep 2010 04:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.993 X-Spam-Level: X-Spam-Status: No, score=-3.993 tagged_above=-999 required=5 tests=[AWL=-1.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vBnUoes31ld for ; Wed, 1 Sep 2010 04:52:29 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id 525A23A67E4 for ; Wed, 1 Sep 2010 04:52:29 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 17EF238C0FB; Wed, 1 Sep 2010 07:52:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1283341979; bh=zISdgPDNP/aEKyZsgxRhogEU9R44b8UV6aja3X3zI2w=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=ZtgOST+xA8w6U9YuoSPfUc4zu6JVcv61C+0hQGu3lgLuWevqTQ+v7t06HJVyhZK+w jfRaz6s2zZC9J8qo2ILTbxtEzIufstdekAaOJrNN77KND0eKIMj0rnz70LZjvQFJ2E wXJMSpK786+xesLOY5NyT1Z+mFp+ChH1uMB/KQb4= From: Scott Kitterman To: domainrep@ietf.org Date: Wed, 1 Sep 2010 07:52:56 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <4C779114.3050109@tana.it> <201008311905.47118.ietf-dkim@kitterman.com> <4C7E3868.5050306@tana.it> In-Reply-To: <4C7E3868.5050306@tana.it> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009010752.57722.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 11:52:30 -0000 On Wednesday, September 01, 2010 07:26:32 am Alessandro Vesely wrote: > In case we are lazy, we should at least avoid to standardize something > that precludes building a cooperative reputation system. For example, > we should provide for a flexible way of resolving who is the > reputation tracker for a given domain. I can see there might some potential benefit for reputation provider A to be able to reply "I don't have an opinion, but reputation provider B might." I'm not certain how well such an operation would scale, but who knows. Scott K From johnl@iecc.com Wed Sep 1 05:25:29 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2EAA3A6F6D for ; Wed, 1 Sep 2010 05:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.916 X-Spam-Level: X-Spam-Status: No, score=-109.916 tagged_above=-999 required=5 tests=[AWL=1.283, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zI8AFkh0P3ZY for ; Wed, 1 Sep 2010 05:25:28 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 07FBC3A6F7A for ; Wed, 1 Sep 2010 05:25:27 -0700 (PDT) Received: (qmail 60914 invoked from network); 1 Sep 2010 12:25:58 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 1 Sep 2010 12:25:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:cc:mime-version:content-type:content-transfer-encoding; s=k1009; olt=johnl@user.iecc.com; bh=K9DCOMXUwVNlBOsqjhno2sXR8srK1gCTfyKbBljLm6w=; b=GJwmJ8zu2fW9iif8J82uXpeqGGAsGrJKWxi3qgBC/OGUUjX77ubYIVLX025WPhU8RZA0i69YC/cWRKW9WF4p/FbkE7t8kw5HIwTPhd49ALgG5pZN/aRVzswwrXfNH05JCIV2aOW2UTQL4bNDbtDMbETnWOxlMMYKBRAYVbT6c1k= Date: 1 Sep 2010 12:25:57 -0000 Message-ID: <20100901122557.7193.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <201009010752.57722.ietf-dkim@kitterman.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 12:25:29 -0000 >I can see there might some potential benefit for reputation provider A to be >able to reply "I don't have an opinion, but reputation provider B might." I'm >not certain how well such an operation would scale, but who knows. If we look at the closest thing we currently have to reputation systems, DNS blacklists and whitelists, nobody does referrals. In some cases one list imports the data from another list, but you don't need a public standard to do that. R's, John From nsb@guppylake.com Wed Sep 1 06:04:27 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C12313A67F1 for ; Wed, 1 Sep 2010 06:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.989 X-Spam-Level: X-Spam-Status: No, score=-0.989 tagged_above=-999 required=5 tests=[AWL=1.610, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7bC5q0X7WDM for ; Wed, 1 Sep 2010 06:04:25 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 794233A6994 for ; Wed, 1 Sep 2010 06:04:25 -0700 (PDT) Received: from 184-205-25-159.pools.spcsdns.net ([184.205.25.159] helo=[192.168.2.3]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OqnD2-00046K-00; Wed, 01 Sep 2010 09:18:36 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20100901100245.17034.qmail@joyce.lan> Date: Wed, 1 Sep 2010 09:04:51 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> References: <20100901100245.17034.qmail@joyce.lan> To: John Levine X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Cc: "domainrep@ietf.org" Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 13:04:27 -0000 On Sep 1, 2010, at 6:02 AM, John Levine wrote: > The idea of the small model was to have something simple and locked = down, > so it was straightforward to interoperate. Needless to say, the more > options you have, the harder it is to interoperate, and the last thing > you want is something that in theory has a zillion options, but the > undocumented reality is that nobody supports more than two of them. I instinctively agree, which is why my inclination was to argue against = the NAICS codes, or almost anything else not in *my* critical path. But = I've come to believe that the few things that are important to any one = person/application are not the few things that another cares about. = Collectively we want lots of different things from a reputation system, = even within our one little email-management example of a reputation = system. If we design a framework with just one set of options, we'll = end up with a long list of options most of which are useless for most = purposes. That's precisely what I'm hoping to preempt.=20 We can solve hundreds of future problems by solving today's problem = right. There is a core protocol here that any reputation system needs = to have, for the format and management of reputation information. We = could design a very simple "reputation for goodness" protocol that = facilitates the interchange of statements that tell us A is rated 0 to = 1.0, but not what for. The rest of our effort, in this group, would be = on a "reputation for email management" sub-protocol -- elaborating the = meaning of each 0 to 1.0 rating with details in the attached MIME = object. Once we're done, other groups will be able to design protocols for = rating other things -- telco/ISP quality of service, blogger ratings, = pundit trustworthiness -- without any protocol design. All they'll need = to do is define the format of the auxiliary MIME object that conveys = essentially all the semantic data related to the rating. I can try writing some of this up as a draft if people think it would be = worthwhile... -- Nathaniel From ietf-dkim@kitterman.com Wed Sep 1 07:01:42 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74FB03A6829 for ; Wed, 1 Sep 2010 07:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[AWL=-1.353, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSuDakWN9iPG for ; Wed, 1 Sep 2010 07:01:35 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id 7D24C3A6893 for ; Wed, 1 Sep 2010 07:01:35 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 6CBEB38C0FB; Wed, 1 Sep 2010 10:02:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1283349725; bh=0N7ZdppXt52T4R0ihym/ts8jUpYBSgJh/oVNtAChHrE=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=mYFG8J6WpAxUgWeMv3zi2MlE3aHyXhx5laiWsOg7AfT2cXG5v2WYT+X7+aoM/5ocy XAGR8ExLr/m4vlgZtyawIObDQ5XUhXQkS8w36mERlckTnVEmbTLaeUAEuvzhLWt9h8 ljuUpzxS8pYvpu8b2GYwGo+InqgBUCZF1/2NFZLY= From: Scott Kitterman To: domainrep@ietf.org Date: Wed, 1 Sep 2010 10:02:02 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <20100901122557.7193.qmail@joyce.lan> In-Reply-To: <20100901122557.7193.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009011002.04168.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 14:01:42 -0000 On Wednesday, September 01, 2010 08:25:57 am John Levine wrote: > >I can see there might some potential benefit for reputation provider A to > >be able to reply "I don't have an opinion, but reputation provider B > >might." I'm not certain how well such an operation would scale, but who > >knows. > > If we look at the closest thing we currently have to reputation systems, > DNS blacklists and whitelists, nobody does referrals. In some cases one > list imports the data from another list, but you don't need a public > standard to do that. I agree. At this point I don't think it hurts to consider the idea, but I doubt it would ever get implemented. Scott K From ajs@shinkuro.com Wed Sep 1 08:56:18 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DA13A6803 for ; Wed, 1 Sep 2010 08:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.182 X-Spam-Level: X-Spam-Status: No, score=-101.182 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMoAvtkfKl4G for ; Wed, 1 Sep 2010 08:56:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 76AC23A6816 for ; Wed, 1 Sep 2010 08:56:17 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 8EB881ECB408 for ; Wed, 1 Sep 2010 15:56:47 +0000 (UTC) Date: Wed, 1 Sep 2010 11:56:45 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100901155645.GJ34607@shinkuro.com> References: <4C779114.3050109@tana.it> <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 15:56:18 -0000 On Mon, Aug 30, 2010 at 07:57:48AM -0400, Nathaniel Borenstein wrote: > I'd like to view Allesandro's large and small queries in the context of long-term extensibility versus short term needs. If we can create a good enough data model for reputation information, the small query (email system using DNS) could effectively express an interoperable subset of the large query (web-based systems doing arbitrarily complex stuff). So, I find myself wondering: what is the fundamental unit of reputation exchange? I really, really like this. I think it's entirely the right way of thinking about it, I think the basic outline of a reputon (which gets points just on the excellent name) is about right, and I think this will be a fruitful way to organize work. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From jdfalk-lists@cybernothing.org Wed Sep 1 14:44:16 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2443D3A6841 for ; Wed, 1 Sep 2010 14:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.411 X-Spam-Level: X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ47NREO1zR2 for ; Wed, 1 Sep 2010 14:44:15 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 122973A684B for ; Wed, 1 Sep 2010 14:44:14 -0700 (PDT) Received: from [192.168.11.34] (c-67-180-233-98.hsd1.ca.comcast.net [67.180.233.98]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o81LigSd022408 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Sep 2010 14:44:44 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o81LigSd022408 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1283377485; bh=Adwb0D3iNW0euCykzCarFb5s25PblKxw9YDumoNvy 2k=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=Vrm/2ZfUqPX8ZqIL 38Mf5vddARKp1Izp/bZPQnPgGL4kAIm1FVJFsBQx6mSMswoA5IGD60JLsUBIg2TcTVF YAaNIVj8Wj4i68m0wbdMiU8L1iM9DRNC4LKl1ySw0lrfVIoiSqkCPmWOyj04Hqr3g/f NxfyMFSCBhISijNyPjJ/8= References: <20100901122557.7193.qmail@joyce.lan> <201009011002.04168.ietf-dkim@kitterman.com> In-Reply-To: <201009011002.04168.ietf-dkim@kitterman.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit From: "J.D. Falk" Date: Wed, 1 Sep 2010 14:44:41 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 21:44:16 -0000 On Sep 1, 2010, at 7:02 AM, Scott Kitterman wrote: > On Wednesday, September 01, 2010 08:25:57 am John Levine wrote: >>> I can see there might some potential benefit for reputation provider A to >>> be able to reply "I don't have an opinion, but reputation provider B >>> might." I'm not certain how well such an operation would scale, but who >>> knows. >> >> If we look at the closest thing we currently have to reputation systems, >> DNS blacklists and whitelists, nobody does referrals. In some cases one >> list imports the data from another list, but you don't need a public >> standard to do that. > > I agree. At this point I don't think it hurts to consider the idea, but I > doubt it would ever get implemented. +1, for all the reasons John described. From jdfalk-lists@cybernothing.org Wed Sep 1 14:47:30 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9369E3A69B4 for ; Wed, 1 Sep 2010 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2S4TjEc259Py for ; Wed, 1 Sep 2010 14:47:27 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id AEAD33A68F2 for ; Wed, 1 Sep 2010 14:47:27 -0700 (PDT) Received: from [192.168.11.34] (c-67-180-233-98.hsd1.ca.comcast.net [67.180.233.98]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o81LltNk022439 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Sep 2010 14:47:57 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o81LltNk022439 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1283377677; bh=HingG2s5aIAxl32sbpkLvzUZQXObUmDfzzwQ9GzVE fQ=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=KKSmNflVS1+HdL/r BdLvM3Ws4fZLL6u127mLPqUkq5uut5qRrj5SMR+DgUYs11wucOlGqy/3KCCnYrApSmR 2q5Er6Bw348HpM0iTqZFBwqFgxdte7RT3mXV7nhIXoK/6bgsub1X7f6sxRQ7UoiQcCS UNc8TtRmrk5b8MtFMaAnU= References: <20100901100245.17034.qmail@joyce.lan> <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> In-Reply-To: <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 1 Sep 2010 14:47:54 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 21:47:30 -0000 (as co-chair, for whatever that's worth) On Sep 1, 2010, at 6:04 AM, Nathaniel Borenstein wrote: > I can try writing some of this up as a draft if people think it would = be worthwhile... Yes, please, and thank you. I think it will help immensely to have = actual drafts to review; these wide-ranging threads can get confusing. From dotis@mail-abuse.org Wed Sep 1 16:18:18 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E333A6898 for ; Wed, 1 Sep 2010 16:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.039 X-Spam-Level: X-Spam-Status: No, score=-105.039 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n16zTDNoOvFG for ; Wed, 1 Sep 2010 16:18:17 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 875053A6872 for ; Wed, 1 Sep 2010 16:18:17 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id B30E1A94672 for ; Wed, 1 Sep 2010 23:18:40 +0000 (UTC) Message-ID: <4C7EDF51.6060309@mail-abuse.org> Date: Wed, 01 Sep 2010 16:18:41 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C779114.3050109@tana.it> <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> <20100901155645.GJ34607@shinkuro.com> In-Reply-To: <20100901155645.GJ34607@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:18:18 -0000 On 9/1/10 8:56 AM, Andrew Sullivan wrote: > I really, really like this. I think it's entirely the right way of > thinking about it, I think the basic outline of a reputon (which gets > points just on the excellent name) is about right, and I think this > will be a fruitful way to organize work. Strongly disagree. Good/bad ratings represent highly abstract information. With such abstraction, it becomes impossible to reasonably aggregate the information being produced on an unknown basis, even when deceptively normalized over the same numeric range. The data underpinning such abstractions can also be conveyed within small responses without needing to obfuscate their basis, such as when expressed as exponents. Information could be reported as incidents of different categories of abusive behavior, together with speculated exchange rates (when available). Reporting these two very different values as some abstract rating dramatically reduces the protective value of the information exchanged. Network providers should be able to utilize their accurate exchange rate information and then aggregate the incidents reported to accurately assess their own networks, for example. How an evaluation relates to the size of their monitoring against the speculated volume of exchanges emitted by a domain will very widely. Some will even inhibit bad ratings whenever a volume of transactions goes above some threshold to minimize support calls. The requester of information should be encouraged to understand their own relationship with the specific domain, and to adjust their actions based upon reported changes of behavior seen in both increased incident rates and traffic volumes. There is little to justify the use of abstractions. It is also important that those reporting incidents, only do so when they have authenticated the domain as the source. The desire to use abstractions might be to avoid responsibility for any negative assertions being made. This is bad when considering the repercussions caused when a domain becomes blocked. Any domain should be able to defend themselves by avoiding abusive behaviors. Incidents collected from assumed sources will strip these domains of such protections. Social reputations might be expressed as being a member of the "big and venerated" club. If a domain reputation service is to develop a "big and venerated" rating that is only able to punish smaller domains based on some scheme where smaller domains are unable to defend themselves, then of course an abstract rating could use just zero and one. Larger domains already enjoy blocking protections caused by the resulting disruption that such action might create. Large domains should still have all incidents reported to offer greater protections for security sensitive operations that may wish to improve protections based upon accurately reported incident information. Of course, any requester would be expected to weigh incidents against speculated volumes, or perhaps their own volume measurements from their networks perspective. For example, by having accurate incident reporting, a network would be better able to determine when they have become the focus of some attack. -Doug From msk@cloudmark.com Wed Sep 1 16:20:41 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 807023A6872 for ; Wed, 1 Sep 2010 16:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.75 X-Spam-Level: X-Spam-Status: No, score=-102.75 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHCvCz0eRffH for ; Wed, 1 Sep 2010 16:20:40 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id C2E613A6855 for ; Wed, 1 Sep 2010 16:20:39 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 1 Sep 2010 16:21:10 -0700 From: "Murray S. Kucherawy" To: Andrew Sullivan , "domainrep@ietf.org" Date: Wed, 1 Sep 2010 16:21:08 -0700 Thread-Topic: [domainrep] In search of the reputon Thread-Index: ActJ7kssGMFtzkEQRbudNpQn8x347gAPe0vQ Message-ID: References: <4C779114.3050109@tana.it> <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> <20100901155645.GJ34607@shinkuro.com> In-Reply-To: <20100901155645.GJ34607@shinkuro.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:20:41 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Wednesday, September 01, 2010 8:57 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] In search of the reputon >=20 > On Mon, Aug 30, 2010 at 07:57:48AM -0400, Nathaniel Borenstein wrote: >=20 > > I'd like to view Allesandro's large and small queries in the context > of long-term extensibility versus short term needs. If we can create a > good enough data model for reputation information, the small query > (email system using DNS) could effectively express an interoperable > subset of the large query (web-based systems doing arbitrarily complex > stuff). So, I find myself wondering: what is the fundamental unit of > reputation exchange? >=20 > I really, really like this. I think it's entirely the right way of > thinking about it, I think the basic outline of a reputon (which gets > points just on the excellent name) is about right, and I think this > will be a fruitful way to organize work. I like it too so far. How do we feel about the basic "reputon" being a pair of scalars, one an ex= pression of reputation and one of confidence in that reputation, say on a s= cale of 0 to 100? (Just as a starting point.) From msk@cloudmark.com Wed Sep 1 16:33:23 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1853A6899 for ; Wed, 1 Sep 2010 16:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=-0.760, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZpcrXEL5Sl6 for ; Wed, 1 Sep 2010 16:33:18 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id D22E23A6872 for ; Wed, 1 Sep 2010 16:33:18 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 1 Sep 2010 16:33:49 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 1 Sep 2010 16:33:48 -0700 Thread-Topic: [domainrep] In search of the reputon Thread-Index: ActJ7kssGMFtzkEQRbudNpQn8x347gAPe0vQAAAqQuA= Message-ID: References: <4C779114.3050109@tana.it> <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> <20100901155645.GJ34607@shinkuro.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] In search of the reputon X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:33:23 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Murray S. Kucherawy > Sent: Wednesday, September 01, 2010 4:21 PM > To: Andrew Sullivan; domainrep@ietf.org > Subject: Re: [domainrep] In search of the reputon >=20 > How do we feel about the basic "reputon" being a pair of scalars, one > an expression of reputation and one of confidence in that reputation, > say on a scale of 0 to 100? (Just as a starting point.) Sorry, that went out half-baked. Given this: > AGENT-A (identified with confidence level X) says that AGENT-B has PERCEN= TAGE likelihood (with confidence > level Y) of ASSERTION. (Some assertions will probably require encapsulat= ing some arbitrary data as part of > the reputon.) AGENT-A is established by where the query lands, so it doesn't need to be p= art of the syntax at all. AGENT-B is established as part of the query to AGENT-A, so it doesn't need = to be part of the reply syntax. PERCENTAGE is easy, a number from 0 to 100. ASSERTION might be implicit in the query, but it might not. So maybe it sh= ould be part of the syntax, or should be able to be part of the syntax. Looking at the short case, I'm inclined to something like using the DNS to = do this. So maybe this, which is close to what John said early on, I think= : - send a DNS TXT query to .._rep. ( identifies the service about which reputation information i= s desired, e.g. "smtp"); this encodes AGENT-A, AGENT-B and ASSERTION implic= itly (e.g. "behaves well") - the reply contains only the PERCENTAGE integer Where multiple services might be of interest, take advantage of caching and= ask the question without "."; the reply would contain "= =3DPERCENTAGE[/Y][ ;=3DPERCENTAGE[/Y] [...]]". This is the minimum. Other tag/value pairs, e.g. the NAICS stuff, could be= included in the reply; recipients encountering such secondary data could/w= ould/should just ignore it if they don't know what it is or don't want it. = What a reputation provider includes that is secondary to the minimum is up= to it and its consumers to specify. For the large query case, HTTP POST and XML with equivalent syntax would wo= rk for me. From msk@cloudmark.com Wed Sep 1 16:34:06 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13A6B3A6899 for ; Wed, 1 Sep 2010 16:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.353 X-Spam-Level: X-Spam-Status: No, score=-103.353 tagged_above=-999 required=5 tests=[AWL=-0.754, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3h6P5+AtSoX for ; Wed, 1 Sep 2010 16:34:04 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id BF8D93A6872 for ; Wed, 1 Sep 2010 16:34:04 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 1 Sep 2010 16:34:35 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 1 Sep 2010 16:34:33 -0700 Thread-Topic: [domainrep] Web of trust (Tentative requirements list) Thread-Index: ActKHuaVlNSJNhbOR/S4COFeZk0WRQAD0j6Q Message-ID: References: <20100901122557.7193.qmail@joyce.lan> <201009011002.04168.ietf-dkim@kitterman.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:34:06 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of J.D. Falk > Sent: Wednesday, September 01, 2010 2:45 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Web of trust (Tentative requirements list) >=20 > > I agree. At this point I don't think it hurts to consider the idea, but= I > > doubt it would ever get implemented. >=20 > +1, for all the reasons John described. +1 as well. From msk@cloudmark.com Wed Sep 1 16:42:41 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9203A6A0A for ; Wed, 1 Sep 2010 16:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.346 X-Spam-Level: X-Spam-Status: No, score=-103.346 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDGlhuF0juY9 for ; Wed, 1 Sep 2010 16:42:38 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id B04A43A6A07 for ; Wed, 1 Sep 2010 16:42:38 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 1 Sep 2010 16:43:09 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 1 Sep 2010 16:43:08 -0700 Thread-Topic: [domainrep] Web of trust (Tentative requirements list) Thread-Index: ActJYQ/JGybSoB2uSIeGCuRYndVqBgAzTrHw Message-ID: References: <4C779114.3050109@tana.it> <4C7D84BF.5060101@mail-abuse.org> <201008311905.47118.ietf-dkim@kitterman.com> In-Reply-To: <201008311905.47118.ietf-dkim@kitterman.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:42:41 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Scott Kitterman > Sent: Tuesday, August 31, 2010 4:06 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Web of trust (Tentative requirements list) >=20 > So I guess we should just give up on DKIM since it's useless as an input = for > reputation for anything else? In any case, this is off topic here, since > assessing the reputation of domain is up to a reputation provider and not > something we can standardize. >=20 > [same sentiment repeated four more times] Absolutely agree. There are at least two anti-abuse vendors in here, and I= don't think any of us believe standardizing our detection and filtering al= gorithms is a good idea, so I don't see how determining reputation is somet= hing that should be standardized either. The IRTF has a draft about how to query an RBL, but there's nothing publish= ed about how one goes about populating an RBL. Indeed it admonishes operat= ors to be aware of the dangers of trusting part of their mail flows to the = RBL operators' reliability. I think that's the way it should be, and it ap= plies to reputation as well. Following that model, we should describe the query/response mechanism ONLY,= as generally and usefully as possible, and not go any further. From dotis@mail-abuse.org Wed Sep 1 17:14:25 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4533A6852 for ; Wed, 1 Sep 2010 17:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.24 X-Spam-Level: X-Spam-Status: No, score=-106.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6b+4k3C8nUn for ; Wed, 1 Sep 2010 17:14:23 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id EE4183A6814 for ; Wed, 1 Sep 2010 17:14:22 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EA74FA94451 for ; Thu, 2 Sep 2010 00:14:46 +0000 (UTC) Message-ID: <4C7EEC77.9030209@mail-abuse.org> Date: Wed, 01 Sep 2010 17:14:47 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C779114.3050109@tana.it> <4C7D84BF.5060101@mail-abuse.org> <201008311905.47118.ietf-dkim@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 00:14:25 -0000 On 9/1/10 4:43 PM, Murray S. Kucherawy wrote: > Absolutely agree. There are at least two anti-abuse vendors in here, and I don't think any of us believe standardizing our detection and filtering algorithms is a good idea, so I don't see how determining reputation is something that should be standardized either. Nothing was said about standardizing detection methods. Nothing was said about standardizing filtering algorithms. Nathaniel suggested reputation information should be in a form that can be aggregated. Such information needs to share a common basis, such as incident counts over time, or estimated exchanges over time, etc. Any effort to standardize reporting a domain's reputation should at the very least include requirements that negative assertions (incident reporting) first authenticate the domain as being the source. It should never be okay to make assumptions about which domain sourced a message. Such assumptions place smaller domains in greater peril, and is inherently unfair. Is there any reason for not making domain authentication a requirement for incident reporting (the basis for reputation)? -Doug From jdfalk-lists@cybernothing.org Wed Sep 1 18:36:39 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE8D3A6A47 for ; Wed, 1 Sep 2010 18:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEZ93m67HU5T for ; Wed, 1 Sep 2010 18:36:33 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 712283A6882 for ; Wed, 1 Sep 2010 18:36:31 -0700 (PDT) Received: from [192.168.11.34] (c-67-180-233-98.hsd1.ca.comcast.net [67.180.233.98]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o821aSum025844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 1 Sep 2010 18:36:31 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o821aSum025844 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1283391391; bh=yMqIZfkePqXadbhiQQnJ01oTpEaBPAsDmtZTRmE8J 1Q=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=ZWE82dyaIWI2d23U WcAtJij5Aal+RNwLg5918Cuf/aeZMXAnAYPsao/9WItoBN2Es3Ob2F5476OBed3LeIK fmtXgYLHypRhaoFssmoN6QtZH4W1UFkwU1OtAI3PW7upK7HSMsMIyHHb3urfw8npeAv DcWBlU80yHDyz3lRhPpVA= References: <4C779114.3050109@tana.it> <4C7D84BF.5060101@mail-abuse.org> <201008311905.47118.ietf-dkim@kitterman.com> <4C7EEC77.9030209@mail-abuse.org> In-Reply-To: <4C7EEC77.9030209@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <6AD28ED4-F5F5-4746-AE1D-6785F486B8BF@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Wed, 1 Sep 2010 18:36:27 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 01:36:39 -0000 On Sep 1, 2010, at 5:14 PM, Douglas Otis wrote: > Any effort to standardize reporting a domain's reputation should at = the very least include requirements that negative assertions (incident = reporting) first authenticate the domain as being the source. It should = never be okay to make assumptions about which domain sourced a message. = Such assumptions place smaller domains in greater peril, and is = inherently unfair. If a user of reputation thinks a Reputation Service is being unfair, = they will stop using that service. Just like today. That can't be built = into a protocol. From dotis@mail-abuse.org Thu Sep 2 02:13:02 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07243A67E6 for ; Thu, 2 Sep 2010 02:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.244 X-Spam-Level: X-Spam-Status: No, score=-106.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd9p1cWO+6xY for ; Thu, 2 Sep 2010 02:13:00 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 1CDF03A6A84 for ; Thu, 2 Sep 2010 02:13:00 -0700 (PDT) Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 4CF63A94602 for ; Thu, 2 Sep 2010 09:13:25 +0000 (UTC) Message-ID: <4C7F6AB5.40808@mail-abuse.org> Date: Thu, 02 Sep 2010 02:13:25 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C779114.3050109@tana.it> <4C7D84BF.5060101@mail-abuse.org> <201008311905.47118.ietf-dkim@kitterman.com> <4C7EEC77.9030209@mail-abuse.org> <6AD28ED4-F5F5-4746-AE1D-6785F486B8BF@cybernothing.org> In-Reply-To: <6AD28ED4-F5F5-4746-AE1D-6785F486B8BF@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Web of trust (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 09:13:02 -0000 On 9/1/10 6:36 PM, J.D. Falk wrote: > On Sep 1, 2010, at 5:14 PM, Douglas Otis wrote: > >> Any effort to standardize reporting a domain's reputation should at the very least include requirements that negative assertions (incident reporting) first authenticate the domain as being the source. It should never be okay to make assumptions about which domain sourced a message. Such assumptions place smaller domains in greater peril, and is inherently unfair. > If a user of reputation thinks a Reputation Service is being unfair, they will stop using that service. Just like today. That can't be built into a protocol. A domain reputation service would not be limited to only email. Do you really mean an RFC is unable to include normative language that specifies fundamental steps essential for ensuring domains are able to defend their reputation? Without such advice, these systems might prove extremely For example: The source of unsolicited message incidents forming a negative assessment for a domain's reputation MUST authenticate the forward-path of the RCPT command as having originated from servers controlled by the assessed domain. SMTP parameters are not covered in the DKIM signature, so only when signed To or CC header fields match the forward-path may the domain be considered authenticated for the purpose of assessing the issuing of unsolicited messages. When there are no matching To or CC header fields or they have not been signed, then the DKIM signing domain MUST BE ignored for the purpose of assessing the issuing of unsolicited messages. Instead, confirming that the EHLO host name resolves the SMTP client, or a TLS cert of SMTP Auth listing a DNS-IDs are possible alternative Authenticated domains suitable for unsolicited message assessment. Smaller domains might wish to utilize subdomains to sign their messages, and then use ADSP dkim=tpa-path to indicate how SMTP clients should be authenticated prior to acceptance, to better protect themselves from reputation services that might fail to authenticate the assessed domain. -Doug From stephen.farrell@cs.tcd.ie Thu Sep 2 13:32:48 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E844A3A6840 for ; Thu, 2 Sep 2010 13:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.813 X-Spam-Level: X-Spam-Status: No, score=-102.813 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxMAnYs0a27r for ; Thu, 2 Sep 2010 13:32:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id AF0DF3A6962 for ; Thu, 2 Sep 2010 13:32:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 054E63E4082; Thu, 2 Sep 2010 21:32:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1283459545; bh=tW8i6X+yRjByGj bkeFdF4DaUQHepKg2DGXgSZyg1KQk=; b=iKIHptSZmc+OHEabBgPgptXT4e8AKq +NLtS+mQMEdKzgc+x0Q8Y5aWOq6lQ0DHCu5gMN17R+QmAgTImS+hM7fyNHYtRfBx 8OtUBl5jq6gzSH/5WMGu4dA3PszEqiSdYLXLZRA3152ndQ8tSufSzwKVtxm6vlS4 Og9crlGk2SulXleQymaBrF4fB70z4GCxKKFWXhm3YQxKObpJKhnJGHCyUtJHBwPM mH3hL7O2ioSo1hmvsi3G64+30bu1BexikFPkqOmLM2Lkj+WPGzRHWfdVuGTv/uqo RJdsrHU/2stZ892fnxJ1DZcaYgz06j8k4H1qSzD2h2ZPP2Fq+9NKT1IQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id hxS9Mo-vywfh; Thu, 2 Sep 2010 21:32:25 +0100 (IST) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id BCE683E4080; Thu, 2 Sep 2010 21:32:25 +0100 (IST) Message-ID: <4C8009D8.4010802@cs.tcd.ie> Date: Thu, 02 Sep 2010 21:32:24 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Rolf E. Sonneveld" References: <4C7C2A72.5070701@sonnection.nl> <4C7CACBC.20607@cs.tcd.ie> <4C7D7C99.3000000@sonnection.nl> In-Reply-To: <4C7D7C99.3000000@sonnection.nl> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] What's in scope and what's not X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 20:32:53 -0000 On 31/08/10 23:05, Rolf E. Sonneveld wrote: ["that" = privacy below] >> For a DNS based solution, that can be achieved to an acceptable >> level for free or nearly free, > > Can you elaborate? DNS queries can mostly get resolved locally once they have a reasonable TTL so the reputation provider doesn't get to see all queries. >> but for the large query/response >> model, it can be a good bit of work. (And may be an example of >> where the "large" protocol differs substantively from the "small" >> one.) > > Why would the large query/response be very different from the small one? > After all, the 'unit of query' is a domain name (or uri), and not the > small amount of data (small query) or large amount of data (large query) > that will be returned for the domain/uri. If e.g. a HTTP model isn't suited for cached responses, then all queries go to the reputation provider which then gets to see everything and can then aggregate all my queries. Including options in queries and/or expecting "fresh" responses makes it hard to cache responses (or makes cache hits unlikely). I suspect a "large" model would include such options. To get around this you have to do something like ask for a chunk of reputation information that covers enough queries that you're happy privacy hasn't been damaged. Can be done, but adds complexity. S. From stephen.farrell@cs.tcd.ie Thu Sep 2 13:36:23 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F225E3A680B for ; Thu, 2 Sep 2010 13:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.803 X-Spam-Level: X-Spam-Status: No, score=-102.803 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DseRdJ0aA-I7 for ; Thu, 2 Sep 2010 13:36:19 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 1434D3A69C3 for ; Thu, 2 Sep 2010 13:36:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4991C3E4082 for ; Thu, 2 Sep 2010 21:36:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1283459798; bh=87VKQCwEbyXWeO QR7/9BfSLQZTJC32Wmi87QyEm1IEE=; b=JAWvrFZlymCITwLzTu1cRzeCy12vmk Wb58xJqMvF53r5LoxDTVlxJ+swTJT/f0A8gb/saZrpBy20cc6TjHJyxuF5eFFm5O KFEcmImcEygBLGYM7j89kt8AVB143CcY3WN3t9C/SSanFPkEVb/Wsgm48rSUxeyB Htq0hOhpWtx6EbE90h6sGMLGemskdcBmWjJcQruWaKC359zRgUnluis+brGzQSq9 IUj2Ki4abk0BlO0kX0x/5/qagq2+E3NK5sy844A34f+0cCnQuuFO9rEmUAmu3w5F b8QsCbzpbHxPeWZX2Xx2oEdHnKu5N3cgpqThGpEvTIcrzEs2qkVt7NvA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id cboPmNzmHuyn for ; Thu, 2 Sep 2010 21:36:38 +0100 (IST) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 160A83E4080 for ; Thu, 2 Sep 2010 21:36:38 +0100 (IST) Message-ID: <4C800AD4.9050003@cs.tcd.ie> Date: Thu, 02 Sep 2010 21:36:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C7C2A72.5070701@sonnection.nl> <4C7CACBC.20607@cs.tcd.ie> <7AF4EB39-F4F1-4C62-8510-99D758C4C1EF@cybernothing.org> In-Reply-To: <7AF4EB39-F4F1-4C62-8510-99D758C4C1EF@cybernothing.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] What's in scope and what's not X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 20:36:23 -0000 On 31/08/10 23:32, J.D. Falk wrote: > On Aug 31, 2010, at 12:18 AM, Stephen Farrell wrote: > >> This may have come up in the requirements thread (if so, sorry, I'm >> catching up from vacation;-), but I think considerations related to >> the requestor's privacy should be in scope. I guess the main >> concern would be that the service provider (or someone else) should >> not be easily able to track the list of domains of interest to a >> requestor. > > Interesting! I hadn't considered this possibility, probably because it doesn't exist in any current reputation framework. Which concern(s) does it solve? Depends on the applications I guess. Probably not a concern if an MTA is asking about mail sender/author/whatever related reputations, but if an end-user is asking about healthcare providers then there's a real privacy issue if the reputation provider gets to see all the domains they go after, e.g. if a browser or other client application automated making the request. There've been a load of times people thought they were being spied on due to the safe web browsing thing, even though that does go to some trouble to do this right. (Client downloads chunks of data and doesn't send the domain/URL itself.) S. From jdfalk-lists@cybernothing.org Thu Sep 2 16:15:09 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FB8C3A677D for ; Thu, 2 Sep 2010 16:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRy20sY51SGX for ; Thu, 2 Sep 2010 16:15:04 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 5A0013A677C for ; Thu, 2 Sep 2010 16:14:59 -0700 (PDT) Received: from [192.168.11.34] (c-67-180-233-98.hsd1.ca.comcast.net [67.180.233.98]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o82NFN0D012585 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 2 Sep 2010 16:15:26 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o82NFN0D012585 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1283469326; bh=p1nXMaddd4TlvQ7ol8Wcj7VGMXIs1fUsnHsQi15Zs x8=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=g2HBaUR6YShKZeoc 8429ixGS5zKS8ghMQQzqnLESJ4VTMaRzboKsNl5MpoJCr183fKqvfbS4sxU+UmFngni uU0K69Q/a0HukfQzVOJLJS1h4HprQnLFMNdRUtCxggP+HxjXANFbtD0S/fh6FsWqJuF Idf4yvmGDdkpOe4qBsM5M= References: <4C7C2A72.5070701@sonnection.nl> <4C7CACBC.20607@cs.tcd.ie> <7AF4EB39-F4F1-4C62-8510-99D758C4C1EF@cybernothing.org> <4C800AD4.9050003@cs.tcd.ie> In-Reply-To: <4C800AD4.9050003@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <920C62C4-918D-407C-B9AA-BE6B0AB45494@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 2 Sep 2010 16:15:22 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] What's in scope and what's not X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 23:15:09 -0000 On Sep 2, 2010, at 1:36 PM, Stephen Farrell wrote: > On 31/08/10 23:32, J.D. Falk wrote: >> On Aug 31, 2010, at 12:18 AM, Stephen Farrell wrote: >>=20 >>> This may have come up in the requirements thread (if so, sorry, I'm >>> catching up from vacation;-), but I think considerations related to >>> the requestor's privacy should be in scope. I guess the main >>> concern would be that the service provider (or someone else) should >>> not be easily able to track the list of domains of interest to a >>> requestor. >>=20 >> Interesting! I hadn't considered this possibility, probably because = it doesn't exist in any current reputation framework. Which concern(s) = does it solve? >=20 > Depends on the applications I guess. Probably not a concern > if an MTA is asking about mail sender/author/whatever related > reputations, but if an end-user is asking about healthcare > providers then there's a real privacy issue if the reputation > provider gets to see all the domains they go after, e.g. if a > browser or other client application automated making the request. Ahh, yeah, that makes sense. I wonder if there's a way to do this such = that it's available for applications where it's appropriate, yet can be = skipped for applications like email where query speed is (for most = users) more important. Or maybe we leave that to a lower layer? From dotis@mail-abuse.org Thu Sep 2 16:24:32 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AAA63A635F for ; Thu, 2 Sep 2010 16:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.252 X-Spam-Level: X-Spam-Status: No, score=-106.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLCr2L7bIY6d for ; Thu, 2 Sep 2010 16:24:31 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 27DF43A6359 for ; Thu, 2 Sep 2010 16:24:31 -0700 (PDT) Received: from US-DOUGLASO-MB.local (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id EAD80A9455A for ; Thu, 2 Sep 2010 23:24:56 +0000 (UTC) Message-ID: <4C803249.3040201@mail-abuse.org> Date: Thu, 02 Sep 2010 16:24:57 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C7C2A72.5070701@sonnection.nl> <4C7CACBC.20607@cs.tcd.ie> <7AF4EB39-F4F1-4C62-8510-99D758C4C1EF@cybernothing.org> <4C800AD4.9050003@cs.tcd.ie> <920C62C4-918D-407C-B9AA-BE6B0AB45494@cybernothing.org> In-Reply-To: <920C62C4-918D-407C-B9AA-BE6B0AB45494@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] What's in scope and what's not X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 23:24:32 -0000 On 9/2/10 4:15 PM, J.D. Falk wrote: > On Sep 2, 2010, at 1:36 PM, Stephen Farrell wrote: > > > Depends on the applications I guess. Probably not a concern if an > > MTA is asking about mail sender/author/whatever related > > reputations, but if an end-user is asking about healthcare > > providers then there's a real privacy issue if the reputation > > provider gets to see all the domains they go after, e.g. if a > > browser or other client application automated making the request. > > Ahh, yeah, that makes sense. I wonder if there's a way to do this > such that it's available for applications where it's appropriate, yet > can be skipped for applications like email where query speed is (for > most users) more important. > > Or maybe we leave that to a lower layer? Why suggest email can't use the strategy taken in safe browsing? Many of our larger customers insisted they wanted full transfers of reputation information rather than individually querying each source, in the interest of speed and network resources. Safe browsing allows updates to bulk information to be in the order of importance, in a form that also protects the reputation service. -Doug From R.E.Sonneveld@sonnection.nl Tue Sep 7 13:22:04 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 218803A6959 for ; Tue, 7 Sep 2010 13:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=-2.867, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id az3R4GSBIHkG for ; Tue, 7 Sep 2010 13:22:02 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id 30F8B3A6AB1 for ; Tue, 7 Sep 2010 13:22:01 -0700 (PDT) Received: from [80.127.135.136] (a80-127-135-136.adsl.xs4all.nl [80.127.135.136]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0L8E0061M8LFM600@lion.sonnection.nl> for domainrep@ietf.org; Tue, 07 Sep 2010 22:22:28 +0200 (CEST) Message-id: <4C869F03.1070006@sonnection.nl> Date: Tue, 07 Sep 2010 22:22:27 +0200 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-version: 1.0 To: domainrep@ietf.org Content-type: multipart/alternative; boundary=------------040701060100070708090703 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1283890948; bh=UEwMpmbOujajgx7oFaB/8Z3o96w/IZG8hLO+byCBw2s=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=kBj43adyFV3e6V1bp+7UTlyKb8oPgivJ/0jFs531pXDTbMG503mhmWt2bmpxG1jei WrltcDwEquqwtOJHHLs/qlfRR+qo5asHx3mBn5GuJzFZRYPuoQ7c2/pOv9n33L/ban TmmrF5XywhdnyxFFxtdMJp4Pyj8rjK1DAPZltrdc= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L8E0061M8LFM600 Subject: [domainrep] Threat Taxonomy (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 20:22:04 -0000 This is a multi-part message in MIME format. --------------040701060100070708090703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, all, in the series 'Tentative Requirement List' here is a summary of what has been discussed on this list regarding a 'threat taxonomy'. The idea of a threat based taxonomy was launched by Nathaniel on 08/22. * Perhaps we should be worrying about taxonomizing threat types rather than industry codes? * We would confine ourselves to the things we actually care about. * We know way more about online threats than we do about categories of organizations. * A threat taxonomy is a fine idea, but it's orthogonoal to an organization taxonomy. There are banks that send spam, and ESPs that don't. * [...] a few, highly logical top-level categories, with a possible proliferation of subcategories. * four categories: 1. sending unsolicited bulk email (subcategories might include fraud) 2. sending email with false/deceptive sender information (subcategory: claiming falsely to be a trusted institution, perhaps with financial and other sub-subcategories) 3. sending active malware content (several subcategories possible) 4. failure to maintain best practices for email servers (possible subcategories for open relays, Non-responsiveness (or unacceptably slow response) to abuse reports, etc.) Comments: * Ad 1: Bulk and fraud are separate. * Ad 2: I see those as functionally separate; fraud to sneak unwanted but otherwise harmless content into inboxes (Gevalia type spam) vs. fraud to enable crime. * So to get back to the threat taxonomy, I suggest to define it in the context of a large query system, but not in the context of the small one. * [...] we may be more successful if we skip that part, and focus on a protocol which could communicate a value for ANY information regarding a particular identifier (likely a domain name.) Then, let the Reputation Providers and Reputation Clients work out which information they want to provide or consume. * Something along the lines of RFC5070 would likely represent a better starting point for general purpose reputation services. http://tools.ietf.org/html/rfc5070 See section 3.10.1 Impact Class Questions: Say we've got a DKIM d= domain in each of these categories. How/why would an MTA treat them differently? --- It seems there is no consensus yet on whether a threat taxonomy is to be part of the reputation query protocol. /rolf --------------040701060100070708090703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all,

in the series 'Tentative Requirement List' here is a summary of what has been discussed on this list regarding a 'threat taxonomy'.

The idea of a threat based taxonomy was launched by Nathaniel on 08/22.

  • Perhaps we should be worrying about taxonomizing threat types rather than industry codes?
  • We would confine ourselves to the things we actually care about.
  • We know way more about online threats than we do about categories of organizations.
  • A threat taxonomy is a fine idea, but it's orthogonoal to an organization taxonomy. There are banks that send spam, and ESPs that don't.
  • [...] a few, highly logical top-level categories, with a possible proliferation of subcategories.
  • four categories:
  1. sending unsolicited bulk email (subcategories might include fraud)
  2. sending email with false/deceptive sender information (subcategory: claiming falsely to be a trusted institution, perhaps with financial and other sub-subcategories)
  3. sending active malware content (several subcategories possible)
  4. failure to maintain best practices for email servers (possible subcategories for open relays, Non-responsiveness (or unacceptably slow response) to abuse reports, etc.)
Comments:

  • Ad 1: Bulk and fraud are separate.
  • Ad 2: I see those as functionally separate; fraud to sneak unwanted but otherwise harmless content into inboxes (Gevalia type spam) vs. fraud to enable crime.
  • So to get back to the threat taxonomy, I suggest to define it in the context of a large query system, but not in the context of the small one.
  • [...] we may be more successful if we skip that part, and focus on a protocol which could communicate a value for ANY information regarding a particular identifier (likely a domain name.) Then, let the Reputation Providers and Reputation Clients work out which information they want to provide or consume.
  • Something along the lines of RFC5070 would likely represent a better starting point for general purpose reputation services.

    http://tools.ietf.org/html/rfc5070

    See section 3.10.1 Impact Class
Questions:

Say we've got a DKIM d= domain in each of these categories. How/why would an MTA treat them differently?

---

It seems there is no consensus yet on whether a threat taxonomy is to be part of the reputation query protocol.

/rolf
--------------040701060100070708090703-- From dotis@mail-abuse.org Tue Sep 7 14:23:31 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22EB3A6966 for ; Tue, 7 Sep 2010 14:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.83 X-Spam-Level: X-Spam-Status: No, score=-104.83 tagged_above=-999 required=5 tests=[AWL=-1.146, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NINWRl2urkCo for ; Tue, 7 Sep 2010 14:23:29 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id C14F03A6959 for ; Tue, 7 Sep 2010 14:23:29 -0700 (PDT) Received: from sjc-office-nat-210.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id 9188BA9447A for ; Tue, 7 Sep 2010 21:23:53 +0000 (UTC) Message-ID: <4C86AD6A.1030704@mail-abuse.org> Date: Tue, 07 Sep 2010 14:23:54 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C869F03.1070006@sonnection.nl> In-Reply-To: <4C869F03.1070006@sonnection.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Threat Taxonomy (Tentative requirements list) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:23:31 -0000 On 9/7/10 1:22 PM, Rolf E. Sonneveld wrote: > Hi, all, > > in the series 'Tentative Requirement List' here is a summary of what > has been discussed on this list regarding a 'threat taxonomy'. > > The idea of a threat based taxonomy was launched by Nathaniel on 08/22. > > * Perhaps we should be worrying about taxonomizing threat types > rather than industry codes? > Yes. I also suspect recipients may want an estimate of the volume of domain traffic, where the requester can then draw their own conclusions in how this relates to incidents being reported. Examples of this information could be seen in sender base, however log e rather than log 10 represents a more applicable scale having better resolution. > > * We would confine ourselves to the things we actually care about. > Perhaps confine the work to things that most care about. > > * We know way more about online threats than we do about > categories of organizations. > Agreed. There could be different extensions specific to different protocols being monitored. > > * A threat taxonomy is a fine idea, but it's orthogonoal to an > organization taxonomy. There are banks that send spam, and ESPs > that don't. > Agreed. > > * [...] a few, highly logical top-level categories, with a > possible proliferation of subcategories. > * four categories: > > 1. sending unsolicited bulk email (subcategories might include > fraud) > 2. sending email with false/deceptive sender information > (subcategory: claiming falsely to be a trusted institution, > perhaps with financial and other sub-subcategories) > 3. sending active malware content (several subcategories possible) > 4. failure to maintain best practices for email servers > (possible subcategories for open relays, Non-responsiveness > (or unacceptably slow response) to abuse reports, etc.) > RFC5070 already provides a reasonable breakdown where policy incidents could relate to 1. unsolicited messages of any volume. 2. could fall into social-engineering. 3. Malware could fall into "admin, user, file, or info-leak depending upon the nature of the threat. Item 4 could fall under policy, misconfiguration, dos, or recon. One might also want to know whether both directions of port 25 are being blocked, except to designated MTAs. Open replays and open proxies might also include CGNs to support IPv6. Not being responsive to abuse reports should have its own category, assuming all reports authenticated the domain before having originated the abuse reports. > Comments: > > * Ad 1: Bulk and fraud are separate. > Of course. > * Ad 2: I see those as functionally separate; fraud to sneak > unwanted but otherwise harmless content into inboxes (Gevalia > type spam) vs. fraud to enable crime. > * So to get back to the threat taxonomy, I suggest to define it in > the context of a large query system, but not in the context of > the small one. > Would large represent pushing hashes for threat categories rather than supporting individual queries? The use of hashes en masse would better protect the privacy of the requestor. > * [...] we may be more successful if we skip that part, and focus > on a protocol which could communicate a value for ANY > information regarding a particular identifier (likely a domain > name.) Then, let the Reputation Providers and Reputation Clients > work out which information they want to provide or consume. > There are already many proprietary services offering nothing that would permit data comparisons l. Measurements need definite > > * Something along the lines of RFC5070 would likely represent a > better starting point for general purpose reputation services. > > http://tools.ietf.org/html/rfc5070 > > See section 3.10.1 Impact Class > > Questions: > > Say we've got a DKIM d= domain in each of these categories. How/why > would an MTA treat them differently? Ask the question the other way around. When d= domain is within one of these categories, an MTA is less likely to accept their messages. There could be a neutral category used to indicate the domain traffic volumes and when the domain was first detected. Depending upon the measurement interval, this might encompass hundreds of millions of different domains. > It seems there is no consensus yet on whether a threat taxonomy is to > be part of the reputation query protocol. An extension of RFC5070 should offer a good starting point. -Doug From nsb@guppylake.com Mon Sep 20 04:09:24 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E26F3A69CD for ; Mon, 20 Sep 2010 04:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_38=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbPn6YNG+Dxv for ; Mon, 20 Sep 2010 04:09:22 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 5917E3A6A53 for ; Mon, 20 Sep 2010 04:09:22 -0700 (PDT) Received: from [213.235.60.14] (helo=[192.168.57.121]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OxeTw-0000Pj-SW for domainrep@ietf.org; Mon, 20 Sep 2010 07:24:25 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Nathaniel Borenstein In-Reply-To: Date: Mon, 20 Sep 2010 12:09:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100901100245.17034.qmail@joyce.lan> <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server1.netnutz.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - guppylake.com Subject: [domainrep] First pass at reputons and the like X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 11:09:24 -0000 On Sep 1, 2010, at 10:47 PM, J.D. Falk wrote: > (as co-chair, for whatever that's worth) >=20 > On Sep 1, 2010, at 6:04 AM, Nathaniel Borenstein wrote: >=20 >> I can try writing some of this up as a draft if people think it would = be worthwhile... >=20 > Yes, please, and thank you. I think it will help immensely to have = actual drafts to review; these wide-ranging threads can get confusing. I'm sorry this took almost 3 weeks; I've been traveling and have = probably tried (or at least hoped) to do too much for this stage. =20 What follows below is partial text for what I envision as set of five = RFC's. I'm completely flexible about nearly all of this -- from the = document structure to those details I've actually put down -- but offer = it up as a starting point for more focused discussion. If people like = the basic structure, I'll volunteer to serve as editor for one or two of = the five documents, most likely the first two. A few notes relative to the discussion on this list: -- I'm hoping that the notion of "Assertions" in this specification will = address Doug's concerns about being too abstract to be useful. -- One thing I've done that hasn't been mentioned on the list is that = I've changed the notion of the rater's confidence in the rating into a = value that expresses the number of data points on which the rating is = based. I think that might make it easier to compare rating in formation = from two different raters. But we might want both, too. -- Also, I don't agree with Murray's comment that AGENT-A (in my = original formulation, called RATER below) and AGENT-B ("RATED") are = unnecessary, because the data might be passed on to a third party after = an initial query. But perhaps they should be optional so that the = initial query can be more efficient, with the information added when = passed on, I'm not sure. -- I apologize if I missed anything substantive in the discussion that I = should have taken into account. Please let me know if I misssed = anything. The draft text follows below. Fire away. -- Nathaniel =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Outline -- Five Documents I. A Model for Reputation Interchange II. A Mime Type for Reputation Information III. A Vocabulary for Email Senders' Reputation IV. Using the DNS for Reputation Interchange (the "small query") V. Using HTTP/XML for Reputation Interchange (the "large query") =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Document #1: A Model for Reputation Interchange This document describes the general model underlying a set of proposals = for the exchange of reputation information on the Internet, and provides = a roadmap to the four additional documents that collectively define a = reputation interchange protocol. It is intended to roughly follow the = recommendations of RFC 4101 for describing a protocol model. The Problem to be Solved Traditionally, most Internet protocols have taken place between = unauthenticated entities. For example, when an email message is = submitted via SMTP, the server typically trusts the self-identification = of the sender, and the sender trusts that the DNS has led it to the = right server. Both kinds of trust are easily betrayed, leading to spam, = phishing, and a host of other ills. In recent years, stronger identity mechanisms have begun to see wider = deployment. For example, the DKIM protocol permits a much higher level = of trust in the identity of the sending domain of an email message. = While this is a major step forward, by itself it does little to solve = the problem of bad actors on the Internet. Even if you can be sure a = message comes from a domain called "trustworthy.com," you don't really = know whether or not that domain is trustworthy. As a practical matter, = the bad actors seem to have adopted DKIM even more rapidly than the good = ones, in the hope that some receiving domains will naively confuse a = confirmation of identity with trustworthiness. The next step, which could usefully be undertaken only in the presence = of such stronger identity mechanisms, is to establish a mechanism by = which mutually trusted parties can exchange information about other = parties. Such information is known as reputation information. While the need for reputation information has been most clear in the = email world, where abuses are commonplace, it is easy to think of = additional uses for such information. It could also be useful in rating = the security of web sites, the quality of service of an ISP or ASP, the = customer satisfaction levels at e-commerce sites, and even things = unrelated to Internet protocols, such as rating plumbers, hotels, or = books. Just as human beings traditionally rely on the recommendations = of trusted parties in the physical world, so too they can be expected to = make use of such reputation information in a variety of applications on = the Internet. Accordingly, this protocol is designed to facilitate a wide range of = reputation applications. However, not all such reputations will need to = convey the same information -- an overall reckoning of goodness versus = badness can be defined generically, but specific applications are likely = to want to describe reputations for multiple attributes; an e-commerce = site might be rated on price, speed of delivery, customer service, etc., = and might receive very different ratings on each. Therefore this = protocol defines a generic mechanism and basic format for reputation = information, while allowing extensions for each application. Information Represented in the Protocol The basic information to be represented in the protocol is fairly = simple, and should include: -- The identity of the entity providing the reputation information -- The level of confidence in that identity being genuine -- The identity of the entity being rated -- The overall rating score for that entity -- The number of data points underlying that score. Beyond this, arbitrary amounts of additional information might be = represented for specific applications of the protocol. Such information = is called the vocabulary for that application. The general protocol = defines a syntax for representing such vocabularies, but each = application must define its own vocabulary. Thus the basic information = must also include -- The name of the application for which the reputation data is being = expressed. For example, a subsequent document will define the reputation vocabulary = for the application "email-sending-domain" which will be used to combat = spam and other abuses of email. Additional documents define a MIME type = for reputation data, and protocols for exchanging such data. Information Flow in the Protocol The basic reputation data represented in the new MIME type can be = transported in any number of ways, like any MIME object. However, it is = anticipated that the typical use of the protcol will be a simple = request/response. One entity will ask a second entity for reputation = data about a third entity, and the second entity will respond with that = data. It is anticipated that a few applications, at least including the = email-sending-domain application, will need a small, lightweight = protocol for such queries and responses, while other applications will = need to be able to retrieve larger and more complex responses. For this = reason, two subsequent documents define two such protocols, one based on = DNS queries and a terse representation, and one based on http queries = with an XML representation. Document #2: A MIME Type for Reputation Information This document defines a MIME type, application/reputon, for the = representation of reputational data. This MIME type has one optional = parameter, "app," which conveys the specific application of reputation = data in use, and usually extends the set of data values that may be = included in the MIME object itself. =20 The body of the MIME type consists of RFC822-style attribute/value = pairs, six of which are standard for all apps: RATER: The identity of the entity providing the reputation information, = generally expressed as a domain name. RATER-AUTHENTICITY: The level of confidence in that identity being = genuine, on a scale of 0 to 1. ASSERTION: A keyword indicating the specific assertion or claim being = rated. In the absence of an app parameter, the reputon can only = indicate generic goodness, with the default assertion "IS-GOOD," but = each app is expected to define additional types of ASSERTION. RATED: The identity of the entity being rated RATING: The overall rating score for that entity, on a scale of 0 to 1. SAMPLE-SIZE: The number of data points underlying that score, possibly = an approximation. Thus, the following example: Content-type: application/reputon RATER: RatingsRUs.com RATER-AUTHENTICITY: 1.0 ASSERTION: IS-GOOD RATED: Alex Rodriguez RATING: 0.99 SAMPLE-SIZE: 50000 indicates that we are absolutely sure (1.0) that the entity = RatingsRUs.com consolidated 50000 data points (perhaps from everyone in = Yankee Stadium) and concluded that Alex Rodriguez is very very good = (0.99) at something. It doesn't tell us what he's good at, and while it = might be playing baseball, it could just as well be dating beautiful = women.=20 A more sophisticated usage would define a baseball app with a = vocabulary of specific assertions, so that this example:: Content-type: application/reputon; app=3Dbaseball RATER: baseball-reference.com RATER-AUTHENTICITY: 1.0 ASSERTION: HITS-FOR-POWER RATED: Alex Rodriguez RATING: 0.99 SAMPLE-SIZE: 50000 would indicate that 50000 fans polled by the entity = baseball-reference.com rate A-Rod very highly in hitting for power, = whereas this example: Content-type: application/reputon; app=3Dbaseball RATER: baseball-reference.com RATER-AUTHENTICITY: 1.0 ASSERTION: CLUTCH-HITTER RATED: Alex Rodriguez RATING: 0.4 SAMPLE-SIZE: 50000 would indicate that a similar poll indicated a somewhat weaker consensus = that A-Rod tends to choke in critical situations. In practice, most usage of reputons is expected to make use of the "app" = parameter to target an application-specific set of assertions. ... TBD: Requirements for authentication of reputation data, e.g. DKIM = signing... Document #3: A Vocabulary for Email Senders' Reputation This document defines the additional possible assertions and other = additional fields for an app value of "email-sending-domain," used to = rate email senders. It will define such values as: SENDS-SPAM PERPETRATES-FRAUD SENDS-MALWARE ... TBD ... See "Threat Taxonomy" thread on domainrep mailing list. Document #4: Using the DNS for Reputation Interchange (the "small = query") ... TBD ... Document #5: Using HTTP/XML for Reputation Interchange (the "large = query") ... TBD ... From stephen.farrell@cs.tcd.ie Mon Sep 20 07:00:29 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267643A6A63 for ; Mon, 20 Sep 2010 07:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.173 X-Spam-Level: X-Spam-Status: No, score=-101.173 tagged_above=-999 required=5 tests=[AWL=-1.774, BAYES_50=0.001, J_CHICKENPOX_38=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4S5Wn8blBJmd for ; Mon, 20 Sep 2010 07:00:22 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 535F23A6926 for ; Mon, 20 Sep 2010 07:00:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 6D7E23E409E; Mon, 20 Sep 2010 15:00:42 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1284991240; bh=gTKmQLbbyZqJxh +k6YilXKRQH5gtCDMsi3xinMkBmAQ=; b=TaIpUVPI2LCB6U6q4NSe1RK3Dv6pWk C+fHEz5Yej4fzc6hDw1E48Kqpufq3f4lEsI9S/vu3TinH3vnzKGc1+WRn9vnlZmT 446odd/+sV9ZAmvXXmfE2CHj21tK1VaAmtQ9X35AitA8mr72ePTL7WnnUHNWXW0k 7fHwaRrZskITnhM7F+EM9OSOMgrPij6/VPoNrVHw2Dl1Xw+/qwW0uO+giSJyRX8N 67h1E7uLwn6F+ZVhApZywgN4SN7buQ2Z5dWEbngN769Lq1CWiwXWbp4HzeG7BpiH pXNeFN3tTnRZb9/TGTdRQjAgy857PEcomHLG9UDys54o/FqS1MJfGUvQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id msxzzxXKP4MT; Mon, 20 Sep 2010 15:00:40 +0100 (IST) Received: from [10.87.48.6] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A14463E409B; Mon, 20 Sep 2010 15:00:36 +0100 (IST) Message-ID: <4C9768FA.8040001@cs.tcd.ie> Date: Mon, 20 Sep 2010 15:00:26 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100826 Lightning/1.0b1 Thunderbird/3.0.7 MIME-Version: 1.0 To: Nathaniel Borenstein References: <20100901100245.17034.qmail@joyce.lan> <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] First pass at reputons and the like X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 14:00:29 -0000 I generally like this, but have two concerns. 1. Who'd ever say anything other than 1.0 for rater authenticity? I guess I just don't get what that's for since its always (?) the rater that's answering the question. 2. I don't see the generic benefit of the #data points. S. On 20/09/10 12:09, Nathaniel Borenstein wrote: > > On Sep 1, 2010, at 10:47 PM, J.D. Falk wrote: > >> (as co-chair, for whatever that's worth) >> >> On Sep 1, 2010, at 6:04 AM, Nathaniel Borenstein wrote: >> >>> I can try writing some of this up as a draft if people think it would be worthwhile... >> >> Yes, please, and thank you. I think it will help immensely to have actual drafts to review; these wide-ranging threads can get confusing. > > I'm sorry this took almost 3 weeks; I've been traveling and have probably tried (or at least hoped) to do too much for this stage. > > What follows below is partial text for what I envision as set of five RFC's. I'm completely flexible about nearly all of this -- from the document structure to those details I've actually put down -- but offer it up as a starting point for more focused discussion. If people like the basic structure, I'll volunteer to serve as editor for one or two of the five documents, most likely the first two. > > A few notes relative to the discussion on this list: > > -- I'm hoping that the notion of "Assertions" in this specification will address Doug's concerns about being too abstract to be useful. > > -- One thing I've done that hasn't been mentioned on the list is that I've changed the notion of the rater's confidence in the rating into a value that expresses the number of data points on which the rating is based. I think that might make it easier to compare rating in formation from two different raters. But we might want both, too. > > -- Also, I don't agree with Murray's comment that AGENT-A (in my original formulation, called RATER below) and AGENT-B ("RATED") are unnecessary, because the data might be passed on to a third party after an initial query. But perhaps they should be optional so that the initial query can be more efficient, with the information added when passed on, I'm not sure. > > -- I apologize if I missed anything substantive in the discussion that I should have taken into account. Please let me know if I misssed anything. > > The draft text follows below. Fire away. -- Nathaniel > ================================= > Outline -- Five Documents > > I. A Model for Reputation Interchange > > II. A Mime Type for Reputation Information > > III. A Vocabulary for Email Senders' Reputation > > IV. Using the DNS for Reputation Interchange (the "small query") > > V. Using HTTP/XML for Reputation Interchange (the "large query") > > ============ > Document #1: A Model for Reputation Interchange > > This document describes the general model underlying a set of proposals for the exchange of reputation information on the Internet, and provides a roadmap to the four additional documents that collectively define a reputation interchange protocol. It is intended to roughly follow the recommendations of RFC 4101 for describing a protocol model. > > The Problem to be Solved > > Traditionally, most Internet protocols have taken place between unauthenticated entities. For example, when an email message is submitted via SMTP, the server typically trusts the self-identification of the sender, and the sender trusts that the DNS has led it to the right server. Both kinds of trust are easily betrayed, leading to spam, phishing, and a host of other ills. > > In recent years, stronger identity mechanisms have begun to see wider deployment. For example, the DKIM protocol permits a much higher level of trust in the identity of the sending domain of an email message. While this is a major step forward, by itself it does little to solve the problem of bad actors on the Internet. Even if you can be sure a message comes from a domain called "trustworthy.com," you don't really know whether or not that domain is trustworthy. As a practical matter, the bad actors seem to have adopted DKIM even more rapidly than the good ones, in the hope that some receiving domains will naively confuse a confirmation of identity with trustworthiness. > > The next step, which could usefully be undertaken only in the presence of such stronger identity mechanisms, is to establish a mechanism by which mutually trusted parties can exchange information about other parties. Such information is known as reputation information. > > While the need for reputation information has been most clear in the email world, where abuses are commonplace, it is easy to think of additional uses for such information. It could also be useful in rating the security of web sites, the quality of service of an ISP or ASP, the customer satisfaction levels at e-commerce sites, and even things unrelated to Internet protocols, such as rating plumbers, hotels, or books. Just as human beings traditionally rely on the recommendations of trusted parties in the physical world, so too they can be expected to make use of such reputation information in a variety of applications on the Internet. > > Accordingly, this protocol is designed to facilitate a wide range of reputation applications. However, not all such reputations will need to convey the same information -- an overall reckoning of goodness versus badness can be defined generically, but specific applications are likely to want to describe reputations for multiple attributes; an e-commerce site might be rated on price, speed of delivery, customer service, etc., and might receive very different ratings on each. Therefore this protocol defines a generic mechanism and basic format for reputation information, while allowing extensions for each application. > > Information Represented in the Protocol > > The basic information to be represented in the protocol is fairly simple, and should include: > > -- The identity of the entity providing the reputation information > > -- The level of confidence in that identity being genuine > > -- The identity of the entity being rated > > -- The overall rating score for that entity > > -- The number of data points underlying that score. > > Beyond this, arbitrary amounts of additional information might be represented for specific applications of the protocol. Such information is called the vocabulary for that application. The general protocol defines a syntax for representing such vocabularies, but each application must define its own vocabulary. Thus the basic information must also include > > -- The name of the application for which the reputation data is being expressed. > > For example, a subsequent document will define the reputation vocabulary for the application "email-sending-domain" which will be used to combat spam and other abuses of email. Additional documents define a MIME type for reputation data, and protocols for exchanging such data. > > Information Flow in the Protocol > > The basic reputation data represented in the new MIME type can be transported in any number of ways, like any MIME object. However, it is anticipated that the typical use of the protcol will be a simple request/response. One entity will ask a second entity for reputation data about a third entity, and the second entity will respond with that data. > > It is anticipated that a few applications, at least including the email-sending-domain application, will need a small, lightweight protocol for such queries and responses, while other applications will need to be able to retrieve larger and more complex responses. For this reason, two subsequent documents define two such protocols, one based on DNS queries and a terse representation, and one based on http queries with an XML representation. > > > Document #2: A MIME Type for Reputation Information > > This document defines a MIME type, application/reputon, for the representation of reputational data. This MIME type has one optional parameter, "app," which conveys the specific application of reputation data in use, and usually extends the set of data values that may be included in the MIME object itself. > > The body of the MIME type consists of RFC822-style attribute/value pairs, six of which are standard for all apps: > > RATER: The identity of the entity providing the reputation information, generally expressed as a domain name. > > RATER-AUTHENTICITY: The level of confidence in that identity being genuine, on a scale of 0 to 1. > > ASSERTION: A keyword indicating the specific assertion or claim being rated. In the absence of an app parameter, the reputon can only indicate generic goodness, with the default assertion "IS-GOOD," but each app is expected to define additional types of ASSERTION. > > RATED: The identity of the entity being rated > > RATING: The overall rating score for that entity, on a scale of 0 to 1. > > SAMPLE-SIZE: The number of data points underlying that score, possibly an approximation. > > Thus, the following example: > > Content-type: application/reputon > > RATER: RatingsRUs.com > RATER-AUTHENTICITY: 1.0 > ASSERTION: IS-GOOD > RATED: Alex Rodriguez > RATING: 0.99 > SAMPLE-SIZE: 50000 > > indicates that we are absolutely sure (1.0) that the entity RatingsRUs.com consolidated 50000 data points (perhaps from everyone in Yankee Stadium) and concluded that Alex Rodriguez is very very good (0.99) at something. It doesn't tell us what he's good at, and while it might be playing baseball, it could just as well be dating beautiful women. > > A more sophisticated usage would define a baseball app with a vocabulary of specific assertions, so that this example:: > > Content-type: application/reputon; app=baseball > > RATER: baseball-reference.com > RATER-AUTHENTICITY: 1.0 > ASSERTION: HITS-FOR-POWER > RATED: Alex Rodriguez > RATING: 0.99 > SAMPLE-SIZE: 50000 > > would indicate that 50000 fans polled by the entity baseball-reference.com rate A-Rod very highly in hitting for power, whereas this example: > > Content-type: application/reputon; app=baseball > > RATER: baseball-reference.com > RATER-AUTHENTICITY: 1.0 > ASSERTION: CLUTCH-HITTER > RATED: Alex Rodriguez > RATING: 0.4 > SAMPLE-SIZE: 50000 > > would indicate that a similar poll indicated a somewhat weaker consensus that A-Rod tends to choke in critical situations. > > In practice, most usage of reputons is expected to make use of the "app" parameter to target an application-specific set of assertions. > > ... TBD: Requirements for authentication of reputation data, e.g. DKIM signing... > > Document #3: A Vocabulary for Email Senders' Reputation > > This document defines the additional possible assertions and other additional fields for an app value of "email-sending-domain," used to rate email senders. It will define such values as: > > SENDS-SPAM > > PERPETRATES-FRAUD > > SENDS-MALWARE > > ... TBD ... See "Threat Taxonomy" thread on domainrep mailing list. > > Document #4: Using the DNS for Reputation Interchange (the "small query") > > ... TBD ... > > Document #5: Using HTTP/XML for Reputation Interchange (the "large query") > > ... TBD ... > > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > From vesely@tana.it Tue Sep 21 00:28:04 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C26FC3A6949 for ; Tue, 21 Sep 2010 00:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.937 X-Spam-Level: X-Spam-Status: No, score=-3.937 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_05=-1.11, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQreTIK2c2f8 for ; Tue, 21 Sep 2010 00:28:03 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6E1E83A67FA for ; Tue, 21 Sep 2010 00:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1285054103; bh=BFYFgi97DssaBNzs+8pF7Zkaa6484o9s8LDXHQY8O/4=; l=2271; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=d+/JGZYvheGSlOx81dCvZ4EVNJ1kpusjV0B3/QPW3p3+AXeJLWAD6hEyWEffTp2MX st1OypDs1Eh4Ae0CJ6mSKERnfifljXNZHlQy5ly6FJGY78/GSzXrR9SuN/tErxnuyS mvrnnPtLAQuJX/7rbI6mqma99C/LiZbdrzuNsEPw= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 21 Sep 2010 09:28:23 +0200 id 00000000005DC035.000000004C985E97.000014CB Message-ID: <4C985E98.9030007@tana.it> Date: Tue, 21 Sep 2010 09:28:24 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: domainrep@ietf.org References: <20100901100245.17034.qmail@joyce.lan> <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> <4C9768FA.8040001@cs.tcd.ie> In-Reply-To: <4C9768FA.8040001@cs.tcd.ie> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] First pass at reputons and the like X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 07:28:04 -0000 On 20/Sep/10 16:00, Stephen Farrell wrote: > On 20/09/10 12:09, Nathaniel Borenstein wrote: > > I generally like this +1 > but have two concerns. > > 1. Who'd ever say anything other than 1.0 for rater > authenticity? I guess I just don't get what that's > for since its always (?) the rater that's answering > the question. This seems somewhat of a misnomer to me, since reputon exchanges should always be authenticated using good crypto stuff. But then also terms like "reliability", or "trustworthiness" can be source of confusion. If I interpret Nathaniel's sketch correctly, this number is the probability that the measure asserted by a rater (for their systems) is also correct for the system at hand. > 2. I don't see the generic benefit of the #data > points. The ability to scale back a rating by the underlying sample size allows to add different ratings and then re-normalize the result. Thus it is possible to aggregate assertions made on different times or by different raters. It will have to be determined whether the (same) aggregation formula is defined for the general model, rather than for each application, rater, or assertion type. >> The basic reputation data represented in the new MIME type can be >> transported in any number of ways, like any MIME object. >> However, it is anticipated that the typical use of the protcol >> will be a simple request/response. One entity will ask a second >> entity for reputation data about a third entity, and the second >> entity will respond with that data. I'd say "that /one/ typical use" will be request/response. A rater may want to submit a reputon to one or more reputation trackers without having received a request for it, e.g. as a consequence of processing abuse reports. >> Document #3: A Vocabulary for Email Senders' Reputation >> >> This document defines the additional possible assertions and >> other additional fields for an app value of >> "email-sending-domain," used to rate email senders. It will >> define such values as: >> >> SENDS-SPAM >> >> PERPETRATES-FRAUD >> >> SENDS-MALWARE Those examples are all negative. For positive ones: IDENTIFIES-USERS HANDLES-REPORTS PUNISHES-SPAMMERS From jdfalk-lists@cybernothing.org Tue Sep 21 14:24:02 2010 Return-Path: X-Original-To: domainrep@core3.amsl.com Delivered-To: domainrep@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4487B3A6852 for ; Tue, 21 Sep 2010 14:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cie2B7bczA6V for ; Tue, 21 Sep 2010 14:24:00 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id C5D213A676A for ; Tue, 21 Sep 2010 14:24:00 -0700 (PDT) Received: from [172.27.35.23] (c-67-180-233-98.hsd1.ca.comcast.net [67.180.233.98]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o8LLOJw6007133 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Sep 2010 14:24:24 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o8LLOJw6007133 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1285104265; bh=GiOt919ZjI8jdqXuHI8vbIjJPdV/5hNhds86bVWfQ rg=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=KdRoYMhwGcrzB/6B B9uJy7/eMvuZppZLZXFzHv0vkFp2g9dHzLIKYCUsk49sMYMDs+N1bU15Clspbmo6FsX EVatzpKdg0oQNfKRTOy7K0FojMSkHz/gny3COXShh0fltbmLRpIxaHIX4NKhbxOpivr XezL9QlPiJecE3vZ9SDB8= References: <20100901100245.17034.qmail@joyce.lan> <9D6F28EE-5D4C-4E4C-A738-4A750D909A97@guppylake.com> <4C9768FA.8040001@cs.tcd.ie> <4C985E98.9030007@tana.it> In-Reply-To: <4C985E98.9030007@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <7FCB9999-1723-4548-B67C-9E19E28B9754@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 21 Sep 2010 14:24:18 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] First pass at reputons and the like X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 21:24:02 -0000 On Sep 21, 2010, at 12:28 AM, Alessandro Vesely wrote: >>> Document #3: A Vocabulary for Email Senders' Reputation >>>=20 >>> This document defines the additional possible assertions and >>> other additional fields for an app value of >>> "email-sending-domain," used to rate email senders. It will >>> define such values as: >>>=20 >>> SENDS-SPAM >>>=20 >>> PERPETRATES-FRAUD >>>=20 >>> SENDS-MALWARE >=20 > Those examples are all negative. For positive ones: >=20 > IDENTIFIES-USERS >=20 > HANDLES-REPORTS >=20 > PUNISHES-SPAMMERS Those all sound like "not-bad" characteristics, which aren't quite the = same as "good"...but in any case I expect we'll see a wide range of = values at first, then in practice we'll discover that a much smaller = list is sufficient. For example, a Reputation Provider whose input data = involves manually testing unsubscribe processes might at first think = they need a PROCESSES-UNSUBSCRIBES assertion, when in fact all they need = is the default IS-GOOD because they only process one type of data. As a general framework, I like this proposal a lot. I think we'll need = to keep SAMPLE-SIZE optional, because for commercial applications that's = likely to be either secret sauce or an improbable boast. Nathaniel, what do you have in mind for the next draft? (A side note: trustworthy.com does not appear to live up to the name.)