From wwwrun@core3.amsl.com Thu Aug 5 11:17:30 2010 Return-Path: X-Original-To: domainrep@ietf.org Delivered-To: domainrep@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0F65C3A6A8A; Thu, 5 Aug 2010 11:17:30 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Cc: domainrep@ietf.org, msk@cloudmark.com, jdfalk-lists@cybernothing.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100805181730.0F65C3A6A8A@core3.amsl.com> Date: Thu, 5 Aug 2010 11:17:30 -0700 (PDT) Subject: [domainrep] New Non-WG Mailing List: domainrep -- Domain Reputation 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, 05 Aug 2010 18:17:30 -0000 A new IETF non-working group email list has been created. List address: domainrep@ietf.org Archive: http://www.ietf.org/mail-archive/web/domainrep/ To subscribe: https://www.ietf.org/mailman/listinfo/domainrep Description: This list is for discussions relating to development and deployment of domain reputation evaluation and communication, a natural offshoot of the work done by the DKIM working group but specifically outside of its charter. For additional information, please contact the list administrators. From vesely@tana.it Sun Aug 8 00:18: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 02CE83A6821 for ; Sun, 8 Aug 2010 00:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 Z9ka5LqQ0SkX for ; Sun, 8 Aug 2010 00:18:46 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id F3E753A67AF for ; Sun, 8 Aug 2010 00:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281251950; bh=4gS/zzOgqKWoVf7asvZ0F4giOfdZzhjkLEVAII/ImRo=; l=1022; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=RdBfzTuDBOK+pppg+UCquj2vllTmzfoX6RDfwFvNnVzfi/4HRp3dDPlN8Qtyg3FI+ aGXyFhuDiVzKjyweyb9cN+bwQ6e7iZ2XSXxqNXEs0D01VuGqZ6x4ytKuND/QVxIMB1 EPP28o6riMVJMGyOMqZvurEKlOfcOtUERG7pfMt8= Received: from [109.112.31.218] ([109.112.31.218]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sun, 08 Aug 2010 09:19:09 +0200 id 00000000005DC035.000000004C5E5A6D.00007689 Message-ID: <4C5E5A61.2060600@tana.it> Date: Sun, 08 Aug 2010 09:18:57 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [domainrep] Are we doing The Right Thing? 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: Sun, 08 Aug 2010 07:18:48 -0000 Hi all, there are various papers, of various practical vs theoretical tone, that describe issues of reputation and its relationship with the Internet. The large majority of them aim at e-commerce issues, and the leid motiv is how to spread the knowledge that a given trader can be trusted by its customers. With email it is the other way around. We tag spammers' IPv4 addresses, but cannot do the same with IPv6 addresses or domain names, because there are too many. The point is that, unlikely positive reputation, tracking negative reputation can be hampered by changing subjects' IDs. A spammer can just change domain name. In facts, considering the complement, or the negation, has always been a logic challenge. Historically, it has lead to antinomies and contradictions in theoretical as well as practical fields. Feedback loops are conceived as a channel for negative reports, and it is challenging to build positive reputations out of them. I hope this list will find out how. From dotis@mail-abuse.org Sun Aug 8 23:35:13 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 7B6E73A6A6D for ; Sun, 8 Aug 2010 23:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.051 X-Spam-Level: X-Spam-Status: No, score=-105.051 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_50=0.001, 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 0PPESnehD3qp for ; Sun, 8 Aug 2010 23:35:10 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 6096C3A6A68 for ; Sun, 8 Aug 2010 23:35:10 -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 7E689A94649 for ; Mon, 9 Aug 2010 06:35:33 +0000 (UTC) Message-ID: <4C5FA1B4.7030700@mail-abuse.org> Date: Sun, 08 Aug 2010 23:35:32 -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: <4C5E5A61.2060600@tana.it> In-Reply-To: <4C5E5A61.2060600@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Are we doing The Right Thing? 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, 09 Aug 2010 06:35:13 -0000 On 8/8/10 12:18 AM, Alessandro Vesely wrote: > Hi all, > there are various papers, of various practical vs theoretical tone, > that describe issues of reputation and its relationship with the > Internet. The large majority of them aim at e-commerce issues, and > the leid motiv is how to spread the knowledge that a given trader can > be trusted by its customers. > > With email it is the other way around. We tag spammers' IPv4 > addresses, but cannot do the same with IPv6 addresses or domain names, > because there are too many. The point is that, unlikely positive > reputation, tracking negative reputation can be hampered by changing > subjects' IDs. A spammer can just change domain name. > > In facts, considering the complement, or the negation, has always been > a logic challenge. Historically, it has lead to antinomies and > contradictions in theoretical as well as practical fields. Feedback > loops are conceived as a channel for negative reports, and it is > challenging to build positive reputations out of them. I hope this > list will find out how. Alessandro, Clearly, default positive reputation breaks down when there is an unlimited supply of alternative identifiers. Your assessment that both IPv6 and domain names represent such a commodity of identifiers is correct, which do not lend themselves to reactive negative assessments. Irrespective of whether a service attempts to make positive or negative assertions, domain reputation, with a possible exception of malicious content, must relate to the administrative domain running the server and issuing the message. The fundamental criteria for deciding whether a message is abusive relates to whether recipients receive a reasonable level of benefit over that of the sender. In other words, where the message is sent is often more significant than actual content, unless of course the content is blatantly abusive. Gaming a reputation service can not be prevented when this service must forgive possible message replay aimed at causing harm to a different domain's reputation. Such harm is permitted whenever the administrative domain running the server is ignored. It also remains difficult to assess the level of recipients receiving a domain's messages compared against messages entering spam-traps. Bot-nets often send messages to other accounts under their control, just to make such relative assessments increasingly difficult. It is fairly typical for bot-nets to distribute email at slow rates through a large number of compromised accounts. When the administrative domain signs their message stream using DKIM, this administrative domain is then able to determine, based upon messages entering spam-traps directly from their servers, which accounts are compromised. A message with a valid signature entering a spam-trap does not offer irrefutable evidence which accounts are compromised, when the message entered the spam-trap from a different administrative domain's server. Domains that have a good reputation can authorize different administrative domains to better ensure the acceptance of their messages that are utilizing these services. If these administrative domains provide services to less reputable administrative domains, it might remain practical to grant acceptance based upon authorization, but only when the different message sources remain apparent to recipients. -Doug From msk@cloudmark.com Mon Aug 9 09:49:54 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 6F05F3A6836 for ; Mon, 9 Aug 2010 09:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.671 X-Spam-Level: X-Spam-Status: No, score=-102.671 tagged_above=-999 required=5 tests=[AWL=-1.931, BAYES_20=-0.74, 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 BwW6OKSnQSII for ; Mon, 9 Aug 2010 09:49:53 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 5F54028C116 for ; Mon, 9 Aug 2010 09:49:53 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 9 Aug 2010 09:50:27 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "domainrep@ietf.org" Date: Mon, 9 Aug 2010 09:50:26 -0700 Thread-Topic: [domainrep] Are we doing The Right Thing? Thread-Index: Acs2ygckAguvYBs8R9u/tpfUNrmNWABGD+AQ Message-ID: References: <4C5E5A61.2060600@tana.it> In-Reply-To: <4C5E5A61.2060600@tana.it> 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] Are we doing The Right Thing? 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, 09 Aug 2010 16:49:54 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Alessandro Vesely > Sent: Sunday, August 08, 2010 12:19 AM > To: domainrep@ietf.org > Subject: [domainrep] Are we doing The Right Thing? >=20 > In facts, considering the complement, or the negation, has always been > a > logic challenge. Historically, it has lead to antinomies and > contradictions > in theoretical as well as practical fields. Feedback loops are > conceived as > a channel for negative reports, and it is challenging to build positive > reputations out of them. I hope this list will find out how. I think there are two discussions to have. One is a lot easier than the ot= her. The two questions are (a) how to compute a reputation, and what that looks = like; and (b) how to communicate a reputation. The second question is stri= ctly technical in nature and thus I believe squarely within the purview of = the IETF as it will specify a protocol and invoke a transport mechanism. T= he first is theoretical or mathematical and constitutes one implementation'= s "secret sauce", and I'm not convinced this is something the IETF needs to= (or should) tackle, at least not yet. Two different reputation vendors might approach things differently, one pro= ducing Boolean reputations and focusing on collection of data about only po= sitive reputation sources, while the other produces a scalar reputation and= focuses on reporting about negative reputation sources. I don't think we = should try to specify which is right; the right answer will be driven by ma= rket forces. Even if there is a "right" algorithm, it's still not for the IETF to specif= y. Although shortest-path-first algorithms are used in routing, for exampl= e, there's no RFC that specifies how Dijkstra's shortest-path-first algorit= hm is executed; there are plenty of mathematical texts for that. In any case, domain reputation is the missing piece to make DKIM truly valu= able; now that we have a verified domain name on a message, we need to be a= ble to associate some value to it. This will be that mechanism. From johnl@iecc.com Mon Aug 9 10:19:47 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 E37743A694A for ; Mon, 9 Aug 2010 10:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.352 X-Spam-Level: X-Spam-Status: No, score=-108.352 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_40=-0.185, 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 Jgq5RungdfLI for ; Mon, 9 Aug 2010 10:19:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 83E613A6B14 for ; Mon, 9 Aug 2010 10:19:46 -0700 (PDT) Received: (qmail 47555 invoked from network); 9 Aug 2010 17:20:20 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Aug 2010 17:20:20 -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=k1008; olt=johnl@user.iecc.com; bh=saYGO46y7eKtKMTDOeTsEQPuo3fUm41mv8U0MqOet4E=; b=1JGqfVdw4wKbZYPWo4RbaiXHg7oKFeAZ7+5+s1x1aKiuUCPiuR49zOPeFLw6JMU4REZfh+oraqJgL89ByhCl67pDU+4drKEeMxDUy3+t9K8CYHBfHM0wDAjJe5PfY1tb2n3kckJF+0bUD3pS5gD7zw9OenaG7jq09mnjcQxDpdk= Date: 9 Aug 2010 17:20:20 -0000 Message-ID: <20100809172020.36809.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] large and small domain reputation 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, 09 Aug 2010 17:19:48 -0000 >The two questions are (a) how to compute a reputation, and what that >looks like; and (b) how to communicate a reputation. The second >question is strictly technical in nature ... Well, sort of. We kicked this around at DAC for a while and didn't get very far. The sense I got was that there are two general sorts of domain rep info, which I might call large and small. The large one is analogous to your 27 page credit report, with all the raw data. You could imagine a rather large XML schema and some sort of HTTP or SOAP query scheme to fetch it. The small one is more like a FICO score. The model I liked represented it as three numbers. The first was a quality score, with a range of something like 0-100. The second was confidence, how sure you are that the quality is right, also 0-100. The third was a NAICS number, what kind of organization it was, on the theory that if you know a sender is a bank or a government, you may be more willing to deliver their mail than if they are a mail-order retailer. That's small enough to do as a DNS lookup. While it's straightforward to specify the bits for either of these, I'm not at all sure that either of them is actually what we want to do. It's a chicken and egg problem, it's premature to standardize until we know what people will use, but people are unlikely to use anything until there's a spec they can implement. If you want, I can do an I-D for the short version. R's, John From msk@cloudmark.com Mon Aug 9 11:11: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 393833A67B3 for ; Mon, 9 Aug 2010 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.565 X-Spam-Level: X-Spam-Status: No, score=-103.565 tagged_above=-999 required=5 tests=[AWL=-0.966, 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 fUGIHB9kIyey for ; Mon, 9 Aug 2010 11:11:16 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 4D5183A6B02 for ; Mon, 9 Aug 2010 11:11:06 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Aug 2010 11:11:40 -0700 From: "Murray S. Kucherawy" To: John Levine , "domainrep@ietf.org" Date: Mon, 9 Aug 2010 11:11:39 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs35yXfargq/DiLSYC0de9+qYjFZgABoeEQ Message-ID: References: <20100809172020.36809.qmail@joyce.lan> In-Reply-To: <20100809172020.36809.qmail@joyce.lan> 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] large and small domain reputation 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, 09 Aug 2010 18:11:23 -0000 > -----Original Message----- > From: John Levine [mailto:johnl@iecc.com] > Sent: Monday, August 09, 2010 10:20 AM > To: domainrep@ietf.org > Cc: Murray S. Kucherawy > Subject: Re: [domainrep] large and small domain reputation >=20 > While it's straightforward to specify the bits for either of these, > I'm not at all sure that either of them is actually what we want to > do. It's a chicken and egg problem, it's premature to standardize > until we know what people will use, but people are unlikely to use > anything until there's a spec they can implement. We had the same problem with DKIM deployment and that didn't stop us. :-) My own experience suggests there will be consumers out there that want each= of the two forms, and there will be a market for both. There will be stil= l others that just want a reputation provider to return a one or a zero. M= y inclination, therefore, is to design a query mechanism that can cater to = either form. That lends itself nicely to HTTP and XML and such. I'm wary of using the DNS for this, for all the usual reasons. From johnl@iecc.com Mon Aug 9 11:18:01 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 494A73A68B1 for ; Mon, 9 Aug 2010 11:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.552 X-Spam-Level: X-Spam-Status: No, score=-109.552 tagged_above=-999 required=5 tests=[AWL=1.647, 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 SnGMMCz6aPsR for ; Mon, 9 Aug 2010 11:17:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id EAC823A67B3 for ; Mon, 9 Aug 2010 11:17:57 -0700 (PDT) Received: (qmail 78421 invoked from network); 9 Aug 2010 18:18:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=d1AdRyvJuKTW4m7PruSdoGBPvGtHy+mJqQ0qjKjSZNI=; b=IgcXSMx5EIh82J+flcSpOx5eO+09PVPI5mlqBGmxzqt3SWPck+YPnps3bwcg+Pu1tBLgmqlaPYTKo6YeVh2F1PQniMu2yw+p87CXeCrjK7/I31uqqCq2un5O72RPZxpCVELGW+SjxUAqbmkGqgHyZgSTiC/4LYwi5EHMZzvnoWA= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 9 Aug 2010 18:18:09 -0000 Date: 9 Aug 2010 14:18:30 -0400 Message-ID: From: "John R. Levine" To: "Murray S. Kucherawy" In-Reply-To: References: <20100809172020.36809.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "domainrep@ietf.org" Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 18:18:01 -0000 >> While it's straightforward to specify the bits for either of these, >> I'm not at all sure that either of them is actually what we want to >> do. It's a chicken and egg problem, it's premature to standardize >> until we know what people will use, but people are unlikely to use >> anything until there's a spec they can implement. > > We had the same problem with DKIM deployment and that didn't stop us. :-) Hey wait, we had DK and to some extent IIM. For this stuff we got nothing. > I'm wary of using the DNS for this, for all the usual reasons. ?? If it's a security question, the official IETF answer (and maybe finally in real life) is DNSSEC. DNS has a lot of advantages if you're trying to do a query per mail message. R's, John From msk@cloudmark.com Mon Aug 9 11:24: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 1B3583A67B3 for ; Mon, 9 Aug 2010 11:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=-0.949, 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 wbn1McP-zmFe for ; Mon, 9 Aug 2010 11:24:03 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 3B2AE3A6B2A for ; Mon, 9 Aug 2010 11:24:03 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Aug 2010 11:24:37 -0700 From: "Murray S. Kucherawy" To: "John R. Levine" Date: Mon, 9 Aug 2010 11:24:37 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs370aiCKQUgpfiTJuyQJTSXT8tCwAAL7pg Message-ID: References: <20100809172020.36809.qmail@joyce.lan> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 18:24:04 -0000 > -----Original Message----- > From: John R. Levine [mailto:johnl@iecc.com] > Sent: Monday, August 09, 2010 11:19 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: RE: [domainrep] large and small domain reputation >=20 > > I'm wary of using the DNS for this, for all the usual reasons. >=20 > ?? >=20 > If it's a security question, the official IETF answer (and maybe > finally > in real life) is DNSSEC. DNS has a lot of advantages if you're trying > to > do a query per mail message. No, more like the "That's not what the DNS is for!" resistance we get in th= e IETF. From dotis@mail-abuse.org Mon Aug 9 11:26: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 4D9E03A6B0E for ; Mon, 9 Aug 2010 11:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.321 X-Spam-Level: X-Spam-Status: No, score=-106.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 GjFAW6bgJ7RU for ; Mon, 9 Aug 2010 11:26:47 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 44FC43A6B23 for ; Mon, 9 Aug 2010 11:26:47 -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 0914FA945FF for ; Mon, 9 Aug 2010 18:27:18 +0000 (UTC) Message-ID: <4C604885.1040302@mail-abuse.org> Date: Mon, 09 Aug 2010 11:27:17 -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: <20100809172020.36809.qmail@joyce.lan> In-Reply-To: <20100809172020.36809.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 18:26:48 -0000 On 8/9/10 10:20 AM, John Levine wrote: >> The two questions are (a) how to compute a reputation, and what that >> looks like; and (b) how to communicate a reputation. The second >> question is strictly technical in nature ... > Well, sort of. We kicked this around at DAC for a while and didn't get > very far. The sense I got was that there are two general sorts of > domain rep info, which I might call large and small. > > The large one is analogous to your 27 page credit report, with all the > raw data. You could imagine a rather large XML schema and some sort of > HTTP or SOAP query scheme to fetch it. > > The small one is more like a FICO score. The model I liked > represented it as three numbers. The first was a quality score, with > a range of something like 0-100. The second was confidence, how sure > you are that the quality is right, also 0-100. The third was a NAICS > number, what kind of organization it was, on the theory that if you > know a sender is a bank or a government, you may be more willing to > deliver their mail than if they are a mail-order retailer. That's > small enough to do as a DNS lookup. > > While it's straightforward to specify the bits for either of these, > I'm not at all sure that either of them is actually what we want to > do. It's a chicken and egg problem, it's premature to standardize > until we know what people will use, but people are unlikely to use > anything until there's a spec they can implement. > > If you want, I can do an I-D for the short version. Rather than being concerned about the query methods and attempting to extract history not provided by infrastructure supporting the domain name service, one solution might be to use TLS certs as a means of identifying the administrative domain of the issuing server. The fact that a domain is large does not mean their messages are not potentially abusive. There are tens of thousands of compromised accounts issuing spam individually at low rates within many of these large domains. It would seem prudent to first understand what is needed to defend reputation rather than setting off to build an edifice on shifting sand. Said another way, one of the most important decisions that needs to be made would be which identity has been adequately authenticated for the purpose of assigning administrative reputations. While DKIM signatures offer a reasonable scheme when dealing with reputation in the positive sense. However, to be effective, the reputation scheme would need to be automated to a high degree. Because DKIM messages can be replayed, and those authorized using SPF might actually be from different administrative domains, these weaknesses could be exploited to undermine a domain's reputation. Such a concern is not about dealing with any type of secret sauce, but is about which identities within email can be adequately authenticated and defended in some automated fashion. -Doug From msk@cloudmark.com Mon Aug 9 11:57:33 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 3176A3A6B2B for ; Mon, 9 Aug 2010 11:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.531 X-Spam-Level: X-Spam-Status: No, score=-103.531 tagged_above=-999 required=5 tests=[AWL=-0.932, 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 NobaTkiZnnjc for ; Mon, 9 Aug 2010 11:57:32 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 5C69D3A6B1A for ; Mon, 9 Aug 2010 11:57:32 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Aug 2010 11:58:06 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 9 Aug 2010 11:58:06 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs38ISOPf4hoPm2SD+JJzn6uaLKxAAA/Zlw Message-ID: References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> In-Reply-To: <4C604885.1040302@mail-abuse.org> 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] large and small domain reputation 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, 09 Aug 2010 18:57:33 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Douglas Otis > Sent: Monday, August 09, 2010 11:27 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > Said another way, one of the most important decisions that needs to be > made would be which identity has been adequately authenticated for the > purpose of assigning administrative reputations. While DKIM signatures > offer a reasonable scheme when dealing with reputation in the positive > sense. >=20 > However, to be effective, the reputation scheme would need to be > automated to a high degree. Because DKIM messages can be replayed, and > those authorized using SPF might actually be from different > administrative domains, these weaknesses could be exploited to > undermine > a domain's reputation. Such a concern is not about dealing with any > type > of secret sauce, but is about which identities within email can be > adequately authenticated and defended in some automated fashion. For the sake of constraining the scope to something we could reasonably hop= e to accomplish, I think we should stipulate that we're only talking first = about how to ask the question and get an answer. We can cover (or decide n= ot to cover) what question to ask later. What's the consensus on this point? I don't want to bite off more than we = can chew, even before we're a working group. From stephen.farrell@cs.tcd.ie Mon Aug 9 12:35: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 ACA063A6B2B for ; Mon, 9 Aug 2010 12:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.832 X-Spam-Level: X-Spam-Status: No, score=-102.832 tagged_above=-999 required=5 tests=[AWL=-0.233, 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 36ydXOWCdScM for ; Mon, 9 Aug 2010 12:35:15 -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 73DB03A69C0 for ; Mon, 9 Aug 2010 12:35:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 51EC93E4072; Mon, 9 Aug 2010 20:35:47 +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=1281382547; bh=s2xeZdGhwQvkUR hg5gcpswCaLMeSB9+S6VlLGrT7ZLo=; b=aQLf+bLW9wO+TUMnJWt73yh5+DV/N0 pdyr7kYTiBUx5iv5c+DUD6v9Bk1amMs3TPrsuA0xrXKQL7BeJoMvdOOsueD22yYJ Izvgpm90n6pejhnqEdja7IrLha0MQ7tK/GivWn9cANqxOg/VigDWtQbO8tvBatU0 VI8yvTFviqCI25j8YyQjkiaHZxT/wVdbEH48ykAofNiR18ItJBHfn1g1EcuG5PpH xbTV4rzbnLKDAO379SSMG+B7f9kVghgSg8zF+ZHLDbtO88AyOd1Btwa8cKr94w+G ORQ8S+iZNIW8GF4dV9uCjoBWUgUOYIZm57vB6HdjaDCyv+4DipeKMF3A== 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 HG8an2OhFWaZ; Mon, 9 Aug 2010 20:35:47 +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 0F6733E406C; Mon, 9 Aug 2010 20:35:46 +0100 (IST) Message-ID: <4C605887.3010101@cs.tcd.ie> Date: Mon, 09 Aug 2010 20:35:35 +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: "Murray S. Kucherawy" References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> 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] large and small domain reputation 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, 09 Aug 2010 19:35:16 -0000 On 09/08/10 19:58, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Douglas Otis >> Sent: Monday, August 09, 2010 11:27 AM >> To: domainrep@ietf.org >> Subject: Re: [domainrep] large and small domain reputation >> >> Said another way, one of the most important decisions that needs to be >> made would be which identity has been adequately authenticated for the >> purpose of assigning administrative reputations. While DKIM signatures >> offer a reasonable scheme when dealing with reputation in the positive >> sense. >> >> However, to be effective, the reputation scheme would need to be >> automated to a high degree. Because DKIM messages can be replayed, and >> those authorized using SPF might actually be from different >> administrative domains, these weaknesses could be exploited to >> undermine >> a domain's reputation. Such a concern is not about dealing with any >> type >> of secret sauce, but is about which identities within email can be >> adequately authenticated and defended in some automated fashion. > > For the sake of constraining the scope to something we could reasonably hope to accomplish, I think we should stipulate that we're only talking first about how to ask the question and get an answer. We can cover (or decide not to cover) what question to ask later. > > What's the consensus on this point? I don't want to bite off more than we can chew, even before we're a working group. Not sure what you mean. Presumably interoperability for the protocol to be defined here (is it still called CRAP? :-) is a goal, so won't you need at least some basic question and answer that everyone can handle? S. From msk@cloudmark.com Mon Aug 9 12:53:51 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 4E8183A6842 for ; Mon, 9 Aug 2010 12:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=-0.916, 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 S3rp-one77nn for ; Mon, 9 Aug 2010 12:53:50 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 74DA93A682F for ; Mon, 9 Aug 2010 12:53:50 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Aug 2010 12:54:24 -0700 From: "Murray S. Kucherawy" To: Stephen Farrell Date: Mon, 9 Aug 2010 12:54:23 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs3+hS1IpqLvgz9SPCJhyxH4yYUAQAAZx5w Message-ID: References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> <4C605887.3010101@cs.tcd.ie> In-Reply-To: <4C605887.3010101@cs.tcd.ie> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 19:53:51 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Monday, August 09, 2010 12:36 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > Not sure what you mean. Presumably interoperability for the protocol > to be defined here (is it still called CRAP? :-) is a goal, so won't > you need at least some basic question and answer that everyone can > handle? For at least the first output of this group, I'm hoping to limit the proble= m-to-solve to just protocol, i.e. specification of how to ask a question an= d get an answer, versus which questions should be asked. I think that conf= uses syntax with semantics and is best left to BCPs or other informational = work. There might also be different reputation services that answer different que= stions, like one service that's for evaluating DKIM "d=3D" domains, versus = one for domains vetted by SPF, versus something else. If our output is mea= nt to be agnostic to such differences, we can't really discuss them at all. From stephen.farrell@cs.tcd.ie Mon Aug 9 13:16:50 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 9218F3A6857 for ; Mon, 9 Aug 2010 13:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.774 X-Spam-Level: X-Spam-Status: No, score=-102.774 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 rH8x4nsx0W5Q for ; Mon, 9 Aug 2010 13:16:49 -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 4BF383A67D0 for ; Mon, 9 Aug 2010 13:16:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 4D2253E4072; Mon, 9 Aug 2010 21:17:22 +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=1281385042; bh=o/nkVxwOMNBZpY UJRiqqSwh4DAxn8Mq6lqaLasHKPM4=; b=N0f6BEcZRlmxNa8G4hX/Eunwjssnxe 7GnnW1RBbsglz54ebMk1soSQ8t3QnT+cL7MYaQV/ik2OCml9HNlBwb1d6cfGFDkH +aNOLwGXGMZ3EhItd4ZIRRNsz8tEqFLOZYb+ddmWGF0xrX585j+AvmmCcuHEoeX+ oQYY2+eMWxddBxR/AedcACblti8rfCYmHyyn3xOKcTYJrLxAa4WaPJaAch+SQvqs pAUjM+yglj6TRy1/RdvkOwEIlbom3zxSDAdmg3PiXT2qfm4YAFf2fvNhxjuKMgsc hcWkzaHRmw0gCaDJaIhidTpljOFYwEQQx9kPWoQxyo40UkRllj1QpVDg== 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 CIHdlq3It9h2; Mon, 9 Aug 2010 21:17:22 +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 05EC93E406C; Mon, 9 Aug 2010 21:17:21 +0100 (IST) Message-ID: <4C60624F.9040901@cs.tcd.ie> Date: Mon, 09 Aug 2010 21:17:19 +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: "Murray S. Kucherawy" References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> <4C605887.3010101@cs.tcd.ie> 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] large and small domain reputation 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, 09 Aug 2010 20:16:50 -0000 On 09/08/10 20:54, Murray S. Kucherawy wrote: >> Not sure what you mean. Presumably interoperability for the protocol >> to be defined here (is it still called CRAP? :-) is a goal, so won't >> you need at least some basic question and answer that everyone can >> handle? > > For at least the first output of this group, I'm hoping to limit the problem-to-solve to just protocol, i.e. specification of how to ask a question and get an answer, versus which questions should be asked. I think that confuses syntax with semantics and is best left to BCPs or other informational work. Hmm. I guess I was thinking how you'd write a charter and the above still seems odd to me at least. > There might also be different reputation services that answer different questions, like one service that's for evaluating DKIM "d=" domains, versus one for domains vetted by SPF, versus something else. If our output is meant to be agnostic to such differences, we can't really discuss them at all. Not necessarily. There may be some use cases that you do discuss, a subset that are supported out of the box and some that could later be supported via some sort of extensibility mechanism. You do need to limit scope, but I'm not sure its really best to try do that by ignoring the semantics of all use cases. (If that's what you meant.) (As a slightly irrelevant example, there's a decade-old thread currently being regurgitated on the PKIX list as to the fact that an OCSP result of "ok" can mean "cert was issued and not revoked" or it could also mean "no such cert was issued" and there's no way for an OCSP client to tell. Regardless of what you think of PKI or OCSP, I think avoiding such things is good;-) S. > > From stephen.farrell@cs.tcd.ie Mon Aug 9 13:18:52 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 B4B493A68B6 for ; Mon, 9 Aug 2010 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.739 X-Spam-Level: X-Spam-Status: No, score=-102.739 tagged_above=-999 required=5 tests=[AWL=-0.140, 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 W+rN-RBHDMjJ for ; Mon, 9 Aug 2010 13:18:52 -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 C163B3A67B1 for ; Mon, 9 Aug 2010 13:18:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id BF69B3E4072 for ; Mon, 9 Aug 2010 21:19:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1281385165; bh=UTEYlloe7jZuroofQQJuMHH8 n9XLyomDGOki5ZFpIik=; b=0MBucEV2Rxs9YwO9j3sHyg8HbT8AmyA4n5tAx/gK iyw4p9GllNpjUMalgZpzCJEz7hVmO9/ex9UFy2YayuJ3dww6FQqqiA5KDTff9j/g K9M2BT6tnBpqzalxY50f0Ur/ufU0m6b1xpGHCSrrPAEPCmddhrF34Gs9P7FuUP7e cjc2GS4avZKIjK2BS65AsAwwGwu0im8xLdRbfcfJxIg/JxaDPPR712e/zCkcG7mO CMXfzgaiOwVAGFxLmYjlfLiZx2v1QKvssNwcITXfl7RzdJeZl4zUk3TkyRav7BTZ zJdUpCyqUYoQgBsomZ9XFAbApcg4sF7nnQH4LqBo+5bx3Q== 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 j+-SNVa6-V7F for ; Mon, 9 Aug 2010 21:19:25 +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 97AC73E406C for ; Mon, 9 Aug 2010 21:19:25 +0100 (IST) Message-ID: <4C6062CC.2030406@cs.tcd.ie> Date: Mon, 09 Aug 2010 21:19: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: "domainrep@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [domainrep] scope question - what apps? 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, 09 Aug 2010 20:18:52 -0000 I think I asked this in Maastricht, but worth doing on the list: for what applications are we considering communicating reputation related information? I assume email is scope, but what else? (If anything.) S. From johnl@iecc.com Mon Aug 9 13:20: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 475F23A67B1 for ; Mon, 9 Aug 2010 13:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.567 X-Spam-Level: X-Spam-Status: No, score=-109.567 tagged_above=-999 required=5 tests=[AWL=1.632, 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 99NO2-nKo+22 for ; Mon, 9 Aug 2010 13:20:04 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 144293A65A6 for ; Mon, 9 Aug 2010 13:20:03 -0700 (PDT) Received: (qmail 40583 invoked from network); 9 Aug 2010 20:20:37 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Aug 2010 20:20:37 -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=k1008; olt=johnl@user.iecc.com; bh=3Mka7aKHrUNWtyc6Sq4LnaLNwM5BYQCaiziKuadsn3Q=; b=d6OVZBoauiPDWNFEuluBN6Wb3oGq6NqDILZiYN879jWropuzqBVByvNPIFlwGQZr5dzoqZf6jdM5h4lyQAlzJW7iyOmhomcnmqbLKsa47v/+WTOkUCnuVB0zekB/lw6E3RDsOOKWPr/c8zgO+Wc3sCutf68yIXVEC6/p9w6UDyA= Date: 9 Aug 2010 20:20:36 -0000 Message-ID: <20100809202036.80554.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] large and small domain reputation 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, 09 Aug 2010 20:20:06 -0000 >For at least the first output of this group, I'm hoping to limit the >problem-to-solve to just protocol, i.e. specification of how to ask a >question and get an answer, versus which questions should be asked. >I think that confuses syntax with semantics and is best left to BCPs >or other informational work. I sympathize with your desire to limit our scope, but it's hard to imagine a protocol that would be equally appropriate for a question whose response would be a single bit and a question whose response could be 400K of XML. If people like my large and small models, we could use those as a starting point, and just characterize the answers as arbitrary MIME blob and under 255 bytes of coded info. R's, John From tony@att.com Mon Aug 9 13:22:01 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 BB9D33A6B2F for ; Mon, 9 Aug 2010 13:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.355 X-Spam-Level: X-Spam-Status: No, score=-106.355 tagged_above=-999 required=5 tests=[AWL=0.244, 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 A0-zJwDx2K+o for ; Mon, 9 Aug 2010 13:22:01 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id C53813A6949 for ; Mon, 9 Aug 2010 13:22:00 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-3.tower-146.messagelabs.com!1281385353!12917139!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.145] Received: (qmail 7001 invoked from network); 9 Aug 2010 20:22:34 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-3.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Aug 2010 20:22:34 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o79KMntI022933 for ; Mon, 9 Aug 2010 16:22:49 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o79KMjI0022836 for ; Mon, 9 Aug 2010 16:22:45 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o79KMSH5030793 for ; Mon, 9 Aug 2010 16:22:29 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.3/8.14.3) with ESMTP id o79KMLOj030712 for ; Mon, 9 Aug 2010 16:22:22 -0400 Received: from [135.70.2.142] (vpn-135-70-2-142.vpn.west.att.com[135.70.2.142]) by maillennium.att.com (mailgw1) with ESMTP id <20100809202220gw100s4po8e> (Authid: tony); Mon, 9 Aug 2010 20:22:21 +0000 X-Originating-IP: [135.70.2.142] Message-ID: <4C60637B.3090604@att.com> Date: Mon, 09 Aug 2010 16:22:19 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Stephen Farrell References: <4C6062CC.2030406@cs.tcd.ie> In-Reply-To: <4C6062CC.2030406@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "domainrep@ietf.org" Subject: Re: [domainrep] scope question - what apps? 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, 09 Aug 2010 20:22:01 -0000 start with email and see if it gets traction? (I could see possible application in sip, sms, http.) Tony Hansen On 8/9/2010 4:19 PM, Stephen Farrell wrote: > I think I asked this in Maastricht, but worth doing on > the list: for what applications are we considering > communicating reputation related information? > > I assume email is scope, but what else? (If anything.) > From msk@cloudmark.com Mon Aug 9 14:35:37 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 C483A3A6AE8 for ; Mon, 9 Aug 2010 14:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.5 X-Spam-Level: X-Spam-Status: No, score=-103.5 tagged_above=-999 required=5 tests=[AWL=-0.901, 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 Vsu4YvFXVrFN for ; Mon, 9 Aug 2010 14:35:36 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id C1A9D3A69CA for ; Mon, 9 Aug 2010 14:35:36 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Mon, 9 Aug 2010 14:36:11 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 9 Aug 2010 14:36:10 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4AFWyMYL4Xj9gQHizEQaGmVCjMQAClzeA Message-ID: References: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: <20100809202036.80554.qmail@joyce.lan> 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] large and small domain reputation 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, 09 Aug 2010 21:35:37 -0000 > -----Original Message----- > From: John Levine [mailto:johnl@iecc.com] > Sent: Monday, August 09, 2010 1:21 PM > To: domainrep@ietf.org > Cc: Murray S. Kucherawy > Subject: Re: [domainrep] large and small domain reputation >=20 > >For at least the first output of this group, I'm hoping to limit the > >problem-to-solve to just protocol, i.e. specification of how to ask a > >question and get an answer, versus which questions should be asked. > >I think that confuses syntax with semantics and is best left to BCPs > >or other informational work. >=20 > I sympathize with your desire to limit our scope, but it's hard to > imagine a protocol that would be equally appropriate for a question > whose response would be a single bit and a question whose response > could be 400K of XML. That's not quite what I'm trying to limit. I'm thinking: Asking about a d= omain name's reputation should be in scope, but deciding how to pick which = domain name to ask about should not be. From dotis@mail-abuse.org Mon Aug 9 14:55: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 BA7553A68B6 for ; Mon, 9 Aug 2010 14:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 84SXuS98ZGHd for ; Mon, 9 Aug 2010 14:55:01 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id DCA553A6848 for ; Mon, 9 Aug 2010 14:55:01 -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 F295AA944B6 for ; Mon, 9 Aug 2010 21:55:30 +0000 (UTC) Message-ID: <4C607952.9070304@mail-abuse.org> Date: Mon, 09 Aug 2010 14:55:30 -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: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 21:55:02 -0000 On 8/9/10 2:36 PM, Murray S. Kucherawy wrote: > That's not quite what I'm trying to limit. I'm thinking: Asking about a domain name's reputation should be in scope, but deciding how to pick which domain name to ask about should not be. Will these implementation guidelines meet your expectations? http://www.surbl.org/implementation.html If not, why not? Secondly, if the WG is to be prevented from defining where a domain in question is derived, what the results mean, and whether the information being relied upon for the reputation can be poisoned, then why should the IETF work on defining such a generic service lacking key protocol elements and security considerations. Unlike a reputation based upon an IP address, applying reputation at the domain is potentially more disruptive. -Doug From ietf-dkim@kitterman.com Mon Aug 9 14:55:05 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 74D1B3A68A2 for ; Mon, 9 Aug 2010 14:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.556 X-Spam-Level: X-Spam-Status: No, score=-4.556 tagged_above=-999 required=5 tests=[AWL=-1.957, 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 XnmoSKs7MfR3 for ; Mon, 9 Aug 2010 14:55:04 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id 407953A6924 for ; Mon, 9 Aug 2010 14:55:04 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 3288F38C0A9; Mon, 9 Aug 2010 17:55:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1281390938; bh=kSUeIw+W0MomJzfqaYc/kCt2lXss/+LvxBakFyi3L14=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=oUGBWWeC0A9R+EEzWl6L4kaCqZhzk6mmDjTCkhrcaeJHcCped768WKAxoac5nf9Yw O6ms19OxggAj1ssK6trCC9mZycSP91a2m4wzBjdcycW/RUjWPs5dDQJfQB+XG1kuwT eQnfQ9YlTJ7WFRRDCin5w0LuQcPCRhpSChK7dY1Y= From: Scott Kitterman To: domainrep@ietf.org Date: Mon, 9 Aug 2010 17:55:32 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008091755.37445.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 21:55:05 -0000 On Monday, August 09, 2010 05:36:10 pm Murray S. Kucherawy wrote: > > -----Original Message----- > > From: John Levine [mailto:johnl@iecc.com] > > Sent: Monday, August 09, 2010 1:21 PM > > To: domainrep@ietf.org > > Cc: Murray S. Kucherawy > > Subject: Re: [domainrep] large and small domain reputation > > > > >For at least the first output of this group, I'm hoping to limit the > > >problem-to-solve to just protocol, i.e. specification of how to ask a > > >question and get an answer, versus which questions should be asked. > > >I think that confuses syntax with semantics and is best left to BCPs > > >or other informational work. > > > > I sympathize with your desire to limit our scope, but it's hard to > > imagine a protocol that would be equally appropriate for a question > > whose response would be a single bit and a question whose response > > could be 400K of XML. > > That's not quite what I'm trying to limit. I'm thinking: Asking about a > domain name's reputation should be in scope, but deciding how to pick > which domain name to ask about should not be. Similarly, I think what data is used to construct the answer should not be either. Scott K From msk@cloudmark.com Mon Aug 9 15:18:37 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 8A8753A69C3 for ; Mon, 9 Aug 2010 15:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.485 X-Spam-Level: X-Spam-Status: No, score=-103.485 tagged_above=-999 required=5 tests=[AWL=-0.886, 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 5U21OsgTNnI4 for ; Mon, 9 Aug 2010 15:18:36 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id C73EE3A6878 for ; Mon, 9 Aug 2010 15:18:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Mon, 9 Aug 2010 15:19:06 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Mon, 9 Aug 2010 15:19:06 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4DZqos1NNG/G1TeS5hud0ZOBVvQAAjx4A Message-ID: References: <20100809202036.80554.qmail@joyce.lan> <4C607952.9070304@mail-abuse.org> In-Reply-To: <4C607952.9070304@mail-abuse.org> 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] large and small domain reputation 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, 09 Aug 2010 22:18:37 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Douglas Otis > Sent: Monday, August 09, 2010 2:56 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > Will these implementation guidelines meet your expectations? >=20 > http://www.surbl.org/implementation.html No. > If not, why not? They specify how to choose which domain names to query. As I said, I thin= k that's not something this work should specify in a normative sense. Incl= uding such discussion in Security Considerations of a document or in a sepa= rate BCP document would probably be fine. Different reputation services might cater to different audiences (DKIM-asse= rted domains, SPF-asserted domains, etc.). I don't want to nail this group= 's work down to just one of those. > Secondly, if the WG is to be prevented from defining where a domain in > question is derived, what the results mean, and whether the information > being relied upon for the reputation can be poisoned, then why should > the IETF work on defining such a generic service lacking key protocol > elements and security considerations. I only said one of those things. Also, your list nicely identifies DKIM (w= hich signs a bunch of otherwise-unverified data), so you're suggesting the = IETF shouldn't have done that work either. From jdfalk-lists@cybernothing.org Mon Aug 9 15:48:15 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 0154C3A6878 for ; Mon, 9 Aug 2010 15:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byNvpKH2DWkG for ; Mon, 9 Aug 2010 15:48:14 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id E44973A6967 for ; Mon, 9 Aug 2010 15:48:13 -0700 (PDT) Received: from rpca-ckerns.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o79MmkYI012949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 9 Aug 2010 16:48:48 -0600 References: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: <20100809202036.80554.qmail@joyce.lan> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <0960D83A-9ECF-449E-8672-5238A159E16D@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 9 Aug 2010 15:48:41 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] large and small domain reputation 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, 09 Aug 2010 22:48:15 -0000 On Aug 9, 2010, at 1:20 PM, John Levine wrote: >> For at least the first output of this group, I'm hoping to limit the >> problem-to-solve to just protocol, i.e. specification of how to ask a >> question and get an answer, versus which questions should be asked. >> I think that confuses syntax with semantics and is best left to BCPs >> or other informational work. >=20 > I sympathize with your desire to limit our scope, but it's hard to > imagine a protocol that would be equally appropriate for a question > whose response would be a single bit and a question whose response > could be 400K of XML. If we look at the ~13 years of work on IPv4 reputation (including binary = blacklist & whitelist output), I can only recall one example of the = gigantic output -- and Karmasphere never really took off, though not for = lack of brains behind it. While it'd be out of scope to /specify/ which actions a Domain = Reputation Client (DRC) may take on a message/connection/etc based on = the answer provided by a Domain Reputation Service (DRS), it might be = okay to talk about those actions at a high level to help set the scope = of this project. For example, a DRC handling DKIM-signed messages = (where the identifier is the d=3D string) could: 1. reject after DATA (though that's rude according to SMTP) 2. generate an NDN 3. make a filtering decision, including but not limited to: 3a. discard it 3b. place in a specific folder, such as "inbox" or "spam" 3c. print it out so the user can stomp on it There'd be a similarly limited list for other identifiers, such as = domains in HTTP URIs in messages or in web browser requests. Considering these as use cases (but again, not specifying actions) could = help us keep the conversation focused so we don't end up with 400K of = XML. From johnl@iecc.com Mon Aug 9 16:48:00 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 10B183A67D4 for ; Mon, 9 Aug 2010 16:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.518 X-Spam-Level: X-Spam-Status: No, score=-109.518 tagged_above=-999 required=5 tests=[AWL=1.681, 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 idHhh9NLVBLk for ; Mon, 9 Aug 2010 16:47:58 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 8D9DD3A697F for ; Mon, 9 Aug 2010 16:47:58 -0700 (PDT) Received: (qmail 40888 invoked from network); 9 Aug 2010 23:48:32 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 9 Aug 2010 23:48:32 -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=k1008; olt=johnl@user.iecc.com; bh=49KGOAxVR0h3rFcmj7uY4PYU4JwTzpM555jpVhYdAGw=; b=Yl99duy213D1cDV6ZYk7ApeV69fKInYAAzkcbOMXTzxPWoJNbit1Xzpf90z5HW4iLSSQdooKGJZuCim628EF2vghJKynuQTVRZPb8J1by3PVcfiomyw86tIPA3b2dxtATj3d8lxkD0gJTCHG0soO1v2fJxASh7Pa0AcTtAiHMD4= Date: 9 Aug 2010 23:48:32 -0000 Message-ID: <20100809234832.31281.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <0960D83A-9ECF-449E-8672-5238A159E16D@cybernothing.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] SMTP nit, was large and small domain reputation 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, 09 Aug 2010 23:48:00 -0000 >1. reject after DATA (though that's rude according to SMTP) It's 100% standards compliant. RFC 5321 sec 4.5.2 even has a discussion about it, noting that a reject after DATA means the message is still the responsibiity of the sending client. I know there used to be MTAs that behaved badly when confronted with reject after data, but it was my impression that most of them have been fixed. R's, John From fergdawgster@gmail.com Mon Aug 9 16:53:37 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 C97973A6900 for ; Mon, 9 Aug 2010 16:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 31V5+GbgI5+U for ; Mon, 9 Aug 2010 16:53:36 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4489C3A67D4 for ; Mon, 9 Aug 2010 16:53:36 -0700 (PDT) Received: by wwj40 with SMTP id 40so3639686wwj.13 for ; Mon, 09 Aug 2010 16:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MukBwMRAE8or/kSO1RPR3BZbQik2K+r66VQ5LcEgces=; b=cGWReW1Q8L+DFlDtYkccMZy7ciJCVohKONgsXlNL/JXxCSa/YVFc90LJBFlXXFC8tP XsP9UOsB5gWY1OTHHNYU118zXtLdg6bYQ+a0oAPIL73jP7iquzdD5DzNtQmkCbDfc6Xm iQRpFBlgGoR46yavbui/Y7vpqSETrsqqUpBik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=abrmwVYNMRJvH2C5i9m4sKqCOZAT8PiflAzD9bqnv9XKBFSQIsHl64yVuGBQ/j1O14 banQRJ+kMOkdwqoDcseK3ZJpRFpbWNXhYcAawAfnbTtlLNxlly5NvtjUurK3hGh0Aagx c2x2U/teK/N5P92X0WGA/VshzmKBVYXpMb+p8= MIME-Version: 1.0 Received: by 10.216.155.74 with SMTP id i52mr14470862wek.26.1281398050135; Mon, 09 Aug 2010 16:54:10 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Mon, 9 Aug 2010 16:54:10 -0700 (PDT) In-Reply-To: <4C60637B.3090604@att.com> References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> Date: Mon, 9 Aug 2010 16:54:10 -0700 Message-ID: From: Paul Ferguson To: Tony Hansen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] scope question - what apps? 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, 09 Aug 2010 23:53:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 That's an interesting perspective. With regards to Internet security, that is debatable. For example, we have both an IP reputation system for e-mail, but a domain & web reputation system based on when/how/if we have seem malicious content on a particular domain (and calculate an applicable score accordingly), thus allowing administrators to set their own thresholds for blocking. I am I correct in assuming that the scope of "reputation" has not been determined yet? Thanks, - - ferg On Mon, Aug 9, 2010 at 1:22 PM, Tony Hansen wrote: > start with email and see if it gets traction? (I could see possible > application in sip, sms, http.) > > Tony Hansen > > On 8/9/2010 4:19 PM, Stephen Farrell wrote: >> >> I think I asked this in Maastricht, but worth doing on >> the list: for what applications are we considering >> communicating reputation related information? >> >> I assume email is scope, but what else? (If anything.) >> > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYJUbq1pz9mNUZTMRAphaAKCa/gZYBsMNHiBR38OjqHqECyZ2IgCfQJLq IoqEvRY1BJs6kurPVA2k26k=3D =3D+Ef5 -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From dotis@mail-abuse.org Mon Aug 9 21:55: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 CDD333A68C0 for ; Mon, 9 Aug 2010 21:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.898 X-Spam-Level: X-Spam-Status: No, score=-105.898 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4, SARE_WEOFFER=0.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 9F-q3AqcNrV5 for ; Mon, 9 Aug 2010 21:55:01 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id B8CA93A6830 for ; Mon, 9 Aug 2010 21:55:01 -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 09AB1A944DB for ; Tue, 10 Aug 2010 04:55:31 +0000 (UTC) Message-ID: <4C60DBC2.6020101@mail-abuse.org> Date: Mon, 09 Aug 2010 21:55:30 -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: <20100809202036.80554.qmail@joyce.lan> <4C607952.9070304@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 04:55:02 -0000 On 8/9/10 3:19 PM, Murray S. Kucherawy wrote: >> On Monday, August 09, 2010 2:56 PM, Douglas Otis wrote: >> >> Will these implementation guidelines meet your expectations? >> >> http://www.surbl.org/implementation.html > No. >> If not, why not? > They specify how to choose which domain names to query. As I said, I think that's not something this work should specify in a normative sense. Including such discussion in Security Considerations of a document or in a separate BCP document would probably be fine. > > Different reputation services might cater to different audiences (DKIM-asserted domains, SPF-asserted domains, etc.). I don't want to nail this group's work down to just one of those. Murray, Sorry, but I am not sure I understand what you meant. The surbl list of top level domains was done to constrain the DoS like effect that the use of random sub-domains might create. Review the approach Google used for listing http related domains: http://code.google.com/apis/safebrowsing/developers_guide_v2.html#ProtocolBasics Their safe browsing protocol is based upon an http lookup. Their service supports two category of lists: phishing and malware. As Paul indicated, we offer a subscription service of this nature using a different type of client. That said, their API requires clients to use assigned access keys. Clearly, with such a control in place, it could support a subscription based service. Their approach represents caching results from tree walking based upon 5 domain levels in depth, which then returns a list of partial sha256 hashes. Partial hashes can then be subsequently queried for specifics at restricted frequencies. The code needed to access this service is included within the browser. For email, centralized caching by a DNS resolver represents a typical mode of making requests against a reputation service. Also, running an http client within an SMTP server might be viewed to represent a security concern. So, how does one avoid walking the DNS tree when making queries against domains that may not be real? The libidn service routines offer a list for the purpose of qualifying top level domains. Perhaps the top level domain issue could be resolved using a separate service shared with many different protocols. Once the top of the name tree has been pruned, any tree walking at least starts with a query representing a possibly valid domain. With a constrained answer, this still leaves tree walking, and perhaps many round trips to obtain an answer. >> Secondly, if the WG is to be prevented from defining where a domain in >> question is derived, what the results mean, and whether the information >> being relied upon for the reputation can be poisoned, then why should >> the IETF work on defining such a generic service lacking key protocol >> elements and security considerations. > I only said one of those things. Also, your list nicely identifies DKIM (which signs a bunch of otherwise-unverified data), so you're suggesting the IETF shouldn't have done that work either. You suggested imposing more than just one scope restriction, but I don't wish to argue about this. So allow me to apologize. The query input used will have a significant affect on the stability of the service. The answer returned must also address specifics. As an additional note, the rate phishing sites change exploited domains limits the benefits obtained from reputation when compared against a proactive approach such as ADSP dkim=all tpa-sig; :^) -Doug From vesely@tana.it Tue Aug 10 02:59:08 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 D30403A687A for ; Tue, 10 Aug 2010 02:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 zsKefm-p1iJg for ; Tue, 10 Aug 2010 02:59:07 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 9CC193A68DF for ; Tue, 10 Aug 2010 02:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281434380; bh=WM3+dOqaXL93MVN/FOjRj4c10T3Xr9BKSij0f6miSN0=; l=991; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=i3qEH9tNmZUFT1TsHak8o43uN12Vc81DdtBzzOxUIRqfGwL1whlnH3SISJBCpNhvm 0KN6cdBhhCg+EoytANPDJtl7ZBJTnkgq8rYG8o8RD4IjBFnD6qo6JrN2YZio1J7KdK VVtFsbrVukTXWID4k4EyQM9lH7kqArgC8mKRMIj0= Received: from [109.112.46.241] ([109.112.46.241]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 10 Aug 2010 11:59:39 +0200 id 00000000005DC035.000000004C61230C.00004F73 Message-ID: <4C6122F8.3050500@tana.it> Date: Tue, 10 Aug 2010 11:59:20 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "domainrep@ietf.org" References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> <4C605887.3010101@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 09:59:08 -0000 Murray S. Kucherawy wrote: > For at least the first output of this group, I'm hoping to limit the > problem-to-solve to just protocol, i.e. specification of how to ask a > question and get an answer, versus which questions should be asked. I > think that confuses syntax with semantics and is best left to BCPs or > other informational work. I thought this has been set up as a non-WG list in order to allow us to discuss semantic issues without being rushed for "real specs". * who/why/when queries a domain's (or server's) reputation? * how come the responder knows the answer? Besides receiving messages, one may query reputation before filing abuse reports, or accepting an FBL subscription. I agree we should avoid to specify the details of reputation algorithms, but we should clearly state what is their input and output. If at all possible, I'd like better some sort of cooperative distributed open database than a number of opaque reputation vendors. From nsb@guppylake.com Tue Aug 10 05:12:45 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 EF24C3A68AC for ; Tue, 10 Aug 2010 05:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 X9DdWwvPGC9n for ; Tue, 10 Aug 2010 05:12:42 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 2AAED3A6847 for ; Tue, 10 Aug 2010 05:12:40 -0700 (PDT) Received: from c-68-42-72-137.hsd1.mi.comcast.net ([68.42.72.137] helo=[192.168.1.6]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ointl-00033X-0q; Tue, 10 Aug 2010 08:25:42 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4C60637B.3090604@att.com> Date: Tue, 10 Aug 2010 08:12:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> To: Tony Hansen 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] scope question - what apps? 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, 10 Aug 2010 12:12:45 -0000 How, if at all, should a domain's reputation differ for different = protocols? It seems to me that if a domain has been compromised or demonstrated to = be antisocial in one context, it is highly likely to be equally = untrustworthy in other contexts as well. If that's the case, reputation = is very nearly protocol-independent. I certainly believe we should start out focused on email, but we = shouldn't rule out the possibility that there's very little that will = differ from protocol to protocol, and we should try to avoid being = unnecessarily email-specific. -- Nathaniel On Aug 9, 2010, at 4:22 PM, Tony Hansen wrote: > start with email and see if it gets traction? (I could see possible = application in sip, sms, http.) >=20 > Tony Hansen >=20 > On 8/9/2010 4:19 PM, Stephen Farrell wrote: >> I think I asked this in Maastricht, but worth doing on >> the list: for what applications are we considering >> communicating reputation related information? >>=20 >> I assume email is scope, but what else? (If anything.) >>=20 > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep From macfisherman@gmail.com Tue Aug 10 07:19: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 772C73A68CB for ; Tue, 10 Aug 2010 07:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.444 X-Spam-Level: X-Spam-Status: No, score=-4.444 tagged_above=-999 required=5 tests=[AWL=-1.845, 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 7h+3150UraGJ for ; Tue, 10 Aug 2010 07:19:05 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 9A7593A6915 for ; Tue, 10 Aug 2010 07:19:05 -0700 (PDT) Received: by qwc9 with SMTP id 9so1057942qwc.31 for ; Tue, 10 Aug 2010 07:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zHzz5PFCwVipigmFdP3v3x1t6R1EccQZ7SMlYBxD6nk=; b=q4Fxajr6wpq4afen5zfMQ9AAq8V/dodtGaPTjcaNhAaydymvaiTjNRNi2skD/t7eJ4 jzi1VYXCafbjMahLdOD5ka2w9iR/BUWC8YouN/4538oSIyfPqLeK66baWXKNOT+ORoyr yp/rhpRUYQIJ+/rcAaqtXj5dWmGL+cifjSnZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=L3e7Q2coyAG62MgkVmk/ZvTnJX3M6/L040xr7Zio6saMsyC4Za8zZr1IfvZVvej993 VmX0eNn3xEWV4Ss2cjVwo8YQKWu2l/hKw8aS8gvEMuP96hYz28KKtHIvi6+upgM9TJXQ yZRKklVVSgYDeLeCarmZfCB5dHQu8XmmOm7Co= MIME-Version: 1.0 Received: by 10.229.218.69 with SMTP id hp5mr8448104qcb.18.1281449980463; Tue, 10 Aug 2010 07:19:40 -0700 (PDT) Received: by 10.229.28.129 with HTTP; Tue, 10 Aug 2010 07:19:39 -0700 (PDT) In-Reply-To: References: <20100809202036.80554.qmail@joyce.lan> Date: Tue, 10 Aug 2010 10:19:39 -0400 Message-ID: From: Jeff Macdonald To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 14:19:06 -0000 On Mon, Aug 9, 2010 at 5:36 PM, Murray S. Kucherawy wro= te: > That's not quite what I'm trying to limit. =A0I'm thinking: =A0Asking abo= ut a domain name's reputation should be in scope, but deciding how to pick = which domain name to ask about should not be. BUT the domain MUST be authenticated, right? -1 billion to using XML +1 to use DNS (heck, Vixie is using it like a database, why can't we) 0 for not specifying the base of a secret recipe. There are a zillion types of beers. They all have in common water, malt, hops & yeast. I'd think an information doc may be useful. --=20 Jeff Macdonald Ayer, MA From sm@resistor.net Tue Aug 10 07:56: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 938F53A6934 for ; Tue, 10 Aug 2010 07:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 jwiayWrDPdWI for ; Tue, 10 Aug 2010 07:56:05 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 810B63A687A for ; Tue, 10 Aug 2010 07:56:05 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o7AEu4mf028940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 07:56:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1281452187; x=1281538587; bh=YH8e2RD77mCU0ThaTrYtAE8HT8X2hz6uyD1cM2BgmAs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Y9a4R9k+WqkSw3TnLghupyaq1lcqD0Np0PkPFf3RcikUaPeCKgxQHnL/lzNP8WOru 3jkfduo+PB+HFBzjL2PRfK1HWtONuLqbuFz2ehHp/JZx5csIET531/gNDA/6zpeS79 A0IWAZ7IzvzTSAL4DJ1nFOxXuxPINBTrJU0Vbvcg= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1281452187; x=1281538587; bh=YH8e2RD77mCU0ThaTrYtAE8HT8X2hz6uyD1cM2BgmAs=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=rsq9UcRPsaEdC7yhuVPced9L6F8Hv6O6WSyp2jt862y+fAgGUYkF72i0gxRIq3eeV p/bGffjdAYVr/JiANHW/velGiJbULYo93LLjn6gMqj8BVKPSvB3fnBdY194sRqFvZu jxix3/2NKm2SP+FVanQYZO1pJB6ySDoeOuhkRs+s= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=yKTdI0ZKD10pDU9TJllXuGXgXPkB7rRivZ9U9K0NJfiHVo/OiE1rd6qUAJI6+KfjG Vkv4kDcllefXcjZGHX0bKSMJrwbHTbG7W/sBJQPWLI7SOx0OKa0ZOSvYCCTlbLFnW55 KVcJK2Uz+OtEgwelvDBorVIRcVVp2nP4NqkRuXM= Message-Id: <6.2.5.6.2.20100810072003.0acc7e40@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 10 Aug 2010 07:55:25 -0700 To: domainrep@ietf.org From: SM In-Reply-To: References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] scope question - what apps? 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, 10 Aug 2010 14:56:07 -0000 At 05:12 10-08-10, Nathaniel Borenstein wrote: >How, if at all, should a domain's reputation differ for different protocols? > >It seems to me that if a domain has been compromised or demonstrated >to be antisocial in one context, it is highly likely to be equally >untrustworthy in other contexts as well. If that's the case, >reputation is very nearly protocol-independent. It's difficult to get people to agree on whether a domain is antisocial or not. A domain may be used to provide more than one service. The domain reputation is generally assessed for a protocol and used as input for the service provided. Reputation can be protocol-independent if promiscuity is protocol-independent. Regards, -sm From dotis@mail-abuse.org Tue Aug 10 09:18:43 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 591293A6914 for ; Tue, 10 Aug 2010 09:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.723 X-Spam-Level: X-Spam-Status: No, score=-105.723 tagged_above=-999 required=5 tests=[AWL=-0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 7dKvBQoGj--1 for ; Tue, 10 Aug 2010 09:18:42 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 7A3103A68F0 for ; Tue, 10 Aug 2010 09:18:42 -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 7A3F3A94576 for ; Tue, 10 Aug 2010 16:19:13 +0000 (UTC) Message-ID: <4C617C05.3020502@mail-abuse.org> Date: Tue, 10 Aug 2010 09:19:17 -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: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] scope question - what apps? 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, 10 Aug 2010 16:18:43 -0000 On 8/10/10 5:12 AM, Nathaniel Borenstein wrote: > How, if at all, should a domain's reputation differ for different protocols? > > It seems to me that if a domain has been compromised or demonstrated to be antisocial in one context, it is highly likely to be equally untrustworthy in other contexts as well. If that's the case, reputation is very nearly protocol-independent. > > I certainly believe we should start out focused on email, but we shouldn't rule out the possibility that there's very little that will differ from protocol to protocol, and we should try to avoid being unnecessarily email-specific. Nathaniel, A domain would not be what is compromised, unless perhaps their DNS is. A server carrying a message on behalf of a domain might be compromised, or it could be used by the domain's marketing department in an ad campaign using a poorly vetted list of email addresses. Such activity may not affect other protocols. When a system is compromised, it often is not limited to exploiting a specific domain or protocol, where blocking a particular domain often will have a very short term impact measured in hours. While a large portion of spam is emitted by compromised systems, the presence of spam does not also equate to the domain having been compromised. If such a measure of being compromised were used, then nearly all major providers would be judged as compromised, due to the level of spam being emitted by their customers through their main servers. Unlike a scheme that attempts to identify the specific system when using IP addresses or server certificates, using a domain as an identifier is far more complex, and far more disruptive when assessed incorrectly. Swapping domain names for IP addresses will not provide the benefit of better isolating compromised systems. This difference should be reflected in taking greater care in how a domain name is obtained, how the domain was authenticated, and the protocol being used. -Doug From msk@cloudmark.com Tue Aug 10 09:43:03 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 7E1623A6888 for ; Tue, 10 Aug 2010 09:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.552 X-Spam-Level: X-Spam-Status: No, score=-103.552 tagged_above=-999 required=5 tests=[AWL=-0.953, 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 9l9wg6McKdvc for ; Tue, 10 Aug 2010 09:43:02 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 56BAD3A68FB for ; Tue, 10 Aug 2010 09:43:02 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 09:43:37 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "domainrep@ietf.org" Date: Tue, 10 Aug 2010 09:43:36 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4csMWJbiI7K7yTomF+bCuV6/z5gAOCpCQ Message-ID: References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> <4C605887.3010101@cs.tcd.ie> <4C6122F8.3050500@tana.it> In-Reply-To: <4C6122F8.3050500@tana.it> 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] large and small domain reputation 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, 10 Aug 2010 16:43:03 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Alessandro Vesely > Sent: Tuesday, August 10, 2010 2:59 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > I thought this has been set up as a non-WG list in order to allow us to > discuss semantic issues without being rushed for "real specs". I don't think one precludes the other. I just want to keep scope creep in = check. =20 > I agree we should avoid to specify the details of reputation > algorithms, but > we should clearly state what is their input and output. I do believe you're agreeing with me. > If at all > possible, > I'd like better some sort of cooperative distributed open database than > a > number of opaque reputation vendors. I believe any protocol a WG produces should be equally operable in either c= ontext. From msk@cloudmark.com Tue Aug 10 09:45: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 6DACB3A699A for ; Tue, 10 Aug 2010 09:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=-0.939, 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 RcvGd2HQkWwt for ; Tue, 10 Aug 2010 09:45:26 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 60E9A3A6984 for ; Tue, 10 Aug 2010 09:45:26 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 Aug 2010 09:46:01 -0700 From: "Murray S. Kucherawy" To: Jeff Macdonald Date: Tue, 10 Aug 2010 09:46:00 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4lxLVCNJiocL8QJSrCQkSrzTItwAFDrcQ Message-ID: References: <20100809202036.80554.qmail@joyce.lan> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 16:45:27 -0000 > -----Original Message----- > From: Jeff Macdonald [mailto:macfisherman@gmail.com] > Sent: Tuesday, August 10, 2010 7:20 AM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > On Mon, Aug 9, 2010 at 5:36 PM, Murray S. Kucherawy > wrote: >=20 > > That's not quite what I'm trying to limit. =A0I'm thinking: =A0Asking > about a domain name's reputation should be in scope, but deciding how > to pick which domain name to ask about should not be. >=20 > BUT the domain MUST be authenticated, right? So no reputation system may be queried if the message was unauthenticated? = That seems nonsensical to me. > -1 billion to using XML Why? > 0 for not specifying the base of a secret recipe. There are a zillion > types of beers. They all have in common water, malt, hops & yeast. I'd > think an information doc may be useful. Sure, but I don't think that sort of R&D is the kind of work the IETF does. From dotis@mail-abuse.org Tue Aug 10 09:51:36 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 1D3923A6888 for ; Tue, 10 Aug 2010 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.335 X-Spam-Level: X-Spam-Status: No, score=-106.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 wFnoHD9y+CML for ; Tue, 10 Aug 2010 09:51:34 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id AFBDB3A6833 for ; Tue, 10 Aug 2010 09:51:34 -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 9B3C7A94555 for ; Tue, 10 Aug 2010 16:52:04 +0000 (UTC) Message-ID: <4C6183B9.3070509@mail-abuse.org> Date: Tue, 10 Aug 2010 09:52:09 -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: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 16:51:36 -0000 On 8/10/10 7:19 AM, Jeff Macdonald wrote: > On Mon, Aug 9, 2010 at 5:36 PM, Murray S. Kucherawy wrote: >> That's not quite what I'm trying to limit. I'm thinking: Asking about a domain name's reputation should be in scope, but deciding how to pick which domain name to ask about should not be. > BUT the domain MUST be authenticated, right? Email does not require a domain to be authenticated before email is accepted. Unless a domain offers some form of authentication, a domain associated with abuse will not have been authenticated. The term authenticate is often misused. Some insist a server carrying a message for a particular domain considers the domain authenticated when the server in question is authorized by the domain. In reality, often such servers handle messages for tens of thousands of domains. Authorization does not authenticate a domain as having originated the message. Authorization is often used to "score" a message in determining acceptance, but it would be wrong to suggest authorized abuse should have a direct relationship with a domain's reputation. > -1 billion to using XML > > +1 to use DNS (heck, Vixie is using it like a database, why can't we) Will all unknown domains be initially assigned a maximal negative rating? If not, will it be necessary to walk a domain tree to find their parent domain? > 0 for not specifying the base of a secret recipe. There are a zillion > types of beers. They all have in common water, malt, hops& yeast. I'd > think an information doc may be useful. I don't know what that means. -Doug From jdfalk-lists@cybernothing.org Tue Aug 10 10:21:44 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 4A44A3A6A85 for ; Tue, 10 Aug 2010 10:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+hOc5o-xnC3 for ; Tue, 10 Aug 2010 10:21:42 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id AFFA33A67E2 for ; Tue, 10 Aug 2010 10:21:42 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-155-21.hsd1.ca.comcast.net [76.126.155.21]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7AHMFgd030805 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Aug 2010 10:22:17 -0700 References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> <4C605887.3010101@cs.tcd.ie> <4C6122F8.3050500@tana.it> In-Reply-To: <4C6122F8.3050500@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <051948C7-5D1C-4B3B-9510-9F2D37EB426C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 10 Aug 2010 10:22:15 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 17:21:44 -0000 On Aug 10, 2010, at 2:59 AM, Alessandro Vesely wrote: > If at all possible, I'd like better some sort of cooperative = distributed open database than a number of opaque reputation vendors. That does seem to be a common perspective within the IETF, ASRG, and = perhaps the open source community in general, and I can certainly = understand why. But I've worked on a number of reputation systems, and = I can't imagine any way that a cooperative distributed open database = could be useful -- simply because it'd be attacked constantly by people = who want to (ahem) change their reputation. For a standards discussion, however, shouldn't we be = implementor-agnostic and try to create a protocol that can work for both = the CDOD and the vendors, within reason? From fergdawgster@gmail.com Tue Aug 10 10:23:44 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 87CAB3A6A85 for ; Tue, 10 Aug 2010 10:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 qkh8gxE4c-Ge for ; Tue, 10 Aug 2010 10:23:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E1AD93A68F3 for ; Tue, 10 Aug 2010 10:23:42 -0700 (PDT) Received: by wyb40 with SMTP id 40so12141432wyb.31 for ; Tue, 10 Aug 2010 10:24:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=i9QVOZNIIUzxEVz5hLebWe2tZPsRYEPfWBcNZ/1TkHk=; b=wULK6+HFFYRDnqbN6iUU3XYKw49KP1DlPvYf8b+1B2HZtMInlCZ6Hv2gPFrBPk5w+H ALmbetRsiVspXTn+ImeVg9E1gQXIzxIv2YN2Gd6x6OFC8Mqm1N0P8qGN9BXyUSgHcCHT fD2ZyATA4wtzqY3G6n6hYdBTDcyDYy2TnutHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TX17T7ZtHkdUHWNdiSdwllwXy9kZNcuS7IkgTkd4pax3unhNvhpCMZFuLSilgTJUlY hRe/1winPXHsC/Vd/X5i6QvLywNxLQDEck5Gb+ex3YSS8LvazTej591JipGPbl9RMa3Y ePuCa/PO/oLPximN29qPCNtbRCQV5l/IFI1AM= MIME-Version: 1.0 Received: by 10.216.188.81 with SMTP id z59mr15417331wem.106.1281461057542; Tue, 10 Aug 2010 10:24:17 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 10:24:16 -0700 (PDT) In-Reply-To: <4C617C05.3020502@mail-abuse.org> References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> Date: Tue, 10 Aug 2010 10:24:16 -0700 Message-ID: From: Paul Ferguson To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] scope question - what apps? 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, 10 Aug 2010 17:23:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 9:19 AM, Douglas Otis wrote: > On 8/10/10 5:12 AM, Nathaniel Borenstein wrote: >> >> How, if at all, should a domain's reputation differ for different >> protocols? >> >> It seems to me that if a domain has been compromised or demonstrated to >> be antisocial in one context, it is highly likely to be equally >> untrustworthy in other contexts as well. If that's the case, reputation >> is very nearly protocol-independent. >> >> I certainly believe we should start out focused on email, but we >> shouldn't rule out the possibility that there's very little that will >> differ from protocol to protocol, and we should try to avoid being >> unnecessarily >> email-specific. > > Nathaniel, > > A domain would not be what is compromised, unless perhaps their DNS is. > Hi Doug, What about 100% malicious domains? There are literally *thousands* of domains that have been created by criminals which have no "legitimate" content, but rather booby-trapped with exploits, malware, etc. In fact, there is entire industry (Black Hat SEO) dedicated to drive traffic (read: unwitting victims) to these domains... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYYszq1pz9mNUZTMRAtRzAJ9txCgFzBDTV1m33LHXk63YaIja6ACaAr9b wY/oSseSTiNjA2QHJZCucH4=3D =3DQWZ4 -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 10:50:59 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 C88B53A6A9A for ; Tue, 10 Aug 2010 10:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=-0.984, 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 5sIk2qmB17Bs for ; Tue, 10 Aug 2010 10:50:58 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id EA67F3A67EF for ; Tue, 10 Aug 2010 10:50:58 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 10:51:34 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 10:51:33 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4sJwKDclauyaGQR2TiWYuTSnGcQAA+H+g Message-ID: References: <20100809172020.36809.qmail@joyce.lan> <4C604885.1040302@mail-abuse.org> <4C605887.3010101@cs.tcd.ie> <4C6122F8.3050500@tana.it> <051948C7-5D1C-4B3B-9510-9F2D37EB426C@cybernothing.org> In-Reply-To: <051948C7-5D1C-4B3B-9510-9F2D37EB426C@cybernothing.org> 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] large and small domain reputation 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, 10 Aug 2010 17:50:59 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of J.D. Falk > Sent: Tuesday, August 10, 2010 10:22 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > That does seem to be a common perspective within the IETF, ASRG, and > perhaps the open source community in general, and I can certainly > understand why. But I've worked on a number of reputation systems, and > I can't imagine any way that a cooperative distributed open database > could be useful -- simply because it'd be attacked constantly by people > who want to (ahem) change their reputation. Vipul's Razor is a collaborative, open, spam classification system, and it'= s reasonably resilient to attacks (AFAIK). It doesn't seem to me that a co= llaborative, distributed, reputation evaluation mechanism is too different. I think we're headed for a world in which, like spam filtering is already, = commercial and open solutions will coexist. > For a standards discussion, however, shouldn't we be implementor- > agnostic and try to create a protocol that can work for both the CDOD > and the vendors, within reason? +1 From msk@cloudmark.com Tue Aug 10 11:40: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 ECAEE3A6A8F for ; Tue, 10 Aug 2010 11:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=-0.985, 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 eBNst65XyRLP for ; Tue, 10 Aug 2010 11:40:30 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id DE5413A6A99 for ; Tue, 10 Aug 2010 11:40:11 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 11:40:38 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 11:40:37 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4AFWyMYL4Xj9gQHizEQaGmVCjMQAuw5RQ Message-ID: References: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: <20100809202036.80554.qmail@joyce.lan> 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] large and small domain reputation 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, 10 Aug 2010 18:40:32 -0000 > -----Original Message----- > From: John Levine [mailto:johnl@iecc.com] > Sent: Monday, August 09, 2010 1:21 PM > To: domainrep@ietf.org > Cc: Murray S. Kucherawy > Subject: Re: [domainrep] large and small domain reputation >=20 > If people like my large and small models, we could use those as a > starting > point, and just characterize the answers as arbitrary MIME blob and > under > 255 bytes of coded info. Seems like a reasonable starting point to me. Any rough sketches you care = to share? From R.E.Sonneveld@sonnection.nl Tue Aug 10 11:59:43 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 2E0B23A67A2 for ; Tue, 10 Aug 2010 11:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.948 X-Spam-Level: X-Spam-Status: No, score=-3.948 tagged_above=-999 required=5 tests=[AWL=-2.444, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 8R9cfp0s-EG8 for ; Tue, 10 Aug 2010 11:59:42 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id BC8343A6896 for ; Tue, 10 Aug 2010 11:59:40 -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 <0L6Y00M1MA4EK000@lion.sonnection.nl> for domainrep@ietf.org; Tue, 10 Aug 2010 21:00:15 +0200 (CEST) Message-id: <4C61A1BE.6060401@sonnection.nl> Date: Tue, 10 Aug 2010 21:00:14 +0200 From: "Rolf E. Sonneveld" User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-version: 1.0 To: "domainrep@ietf.org" References: <20100809202036.80554.qmail@joyce.lan> In-reply-to: Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1281466815; bh=juIqkcc4VQbkBZ2Yyxiwyg/I5EZqXmDD3A3PCosru9Q=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TfymEtrVcGquv2KLq6mNmQwTW6C6qxcfPY3KDVw06zvzT/ffF00/YzxbbHt5qghRg hlEwHnabFtPr+gWC1itB82v83gdHjHazNwjDUbqA/ucB/5IT0Me4kiZtO3L7PF1IOM iKR4dsscCyLtmmBM4XmV8bfpPCl23PHY8UCqh7UI= X-DKIM: OpenDKIM Filter v1.2.2 lion.sonnection.nl 0L6Y00M1MA4EK000 Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 18:59:43 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: John Levine [mailto:johnl@iecc.com] >> Sent: Monday, August 09, 2010 1:21 PM >> To: domainrep@ietf.org >> Cc: Murray S. Kucherawy >> Subject: Re: [domainrep] large and small domain reputation >> >> If people like my large and small models, we could use those as a >> starting >> point, and just characterize the answers as arbitrary MIME blob and >> under >> 255 bytes of coded info. >> > > Seems like a reasonable starting point to me. Any rough sketches you care to share? > before we go any further, can we change the title of 'large and small domain reputation' into something different? At first glance the 'large' and 'small' seemed to be adjectives to the word 'domain', and not to the combined concept of 'domain reputation'. We're not talking about small domains or large domains, do we? So what would be a proper name to use? /rolf From macfisherman@gmail.com Tue Aug 10 12:08:11 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 583633A6A99 for ; Tue, 10 Aug 2010 12:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.306 X-Spam-Level: X-Spam-Status: No, score=-4.306 tagged_above=-999 required=5 tests=[AWL=-1.707, 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 14CX4jMzP7xW for ; Tue, 10 Aug 2010 12:08:09 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 856393A69D1 for ; Tue, 10 Aug 2010 12:08:09 -0700 (PDT) Received: by qyk1 with SMTP id 1so3412774qyk.10 for ; Tue, 10 Aug 2010 12:08:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fOWWxfzNkTAdFO2JMd441QPpADmSPSTga7e1gmCjqp4=; b=gEKa74UO1h0JaiDBc6qEeyoZM6M3YLGozfwWXwvJ+WHsDknyTN0HHvNtbvZNl8DeJq 0mm8aQIzjq7pnFaJAi/B+tGLyGw3qILJNA7kMrkuJsE5vSr567ajGJZDJVeDZvOotJWu oU3KtlO5qqEER/0RouNh4dUPqY2hP15FYWCEU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NvXCu/MKp1JS5xMCIxwJ/GftWkzFYidWa8y0A8KxCRynNVGlurYA8vWgUn8kVf2/La dqij1XVRAdPeBSdpm2rQwMO/LDq4HnO7IGyOLemksuN+kDPIuYW+tBq2fJgieeypuF17 KvFl9lCd+ag+eiDoUukNl6dJjcTqAMrM52dys= MIME-Version: 1.0 Received: by 10.229.232.14 with SMTP id js14mr8800377qcb.191.1281467324110; Tue, 10 Aug 2010 12:08:44 -0700 (PDT) Received: by 10.229.28.129 with HTTP; Tue, 10 Aug 2010 12:08:44 -0700 (PDT) In-Reply-To: References: <20100809202036.80554.qmail@joyce.lan> Date: Tue, 10 Aug 2010 15:08:44 -0400 Message-ID: From: Jeff Macdonald To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 19:08:11 -0000 On Tue, Aug 10, 2010 at 12:46 PM, Murray S. Kucherawy w= rote: >> -----Original Message----- >> From: Jeff Macdonald [mailto:macfisherman@gmail.com] >> Sent: Tuesday, August 10, 2010 7:20 AM >> To: Murray S. Kucherawy >> Cc: domainrep@ietf.org >> Subject: Re: [domainrep] large and small domain reputation >> >> On Mon, Aug 9, 2010 at 5:36 PM, Murray S. Kucherawy >> wrote: >> >> > That's not quite what I'm trying to limit. =A0I'm thinking: =A0Asking >> about a domain name's reputation should be in scope, but deciding how >> to pick which domain name to ask about should not be. >> >> BUT the domain MUST be authenticated, right? > > So no reputation system may be queried if the message was unauthenticated= ? =A0That seems nonsensical to me. You lost me. A spoofed message with spoofed domains is perfectly acceptable for input into a domain reputation system? I'm coming up blank here what other word to use besides authenticated. Maybe Doug has a point. Maybe authenticated isn't the right word but it is the only one I can think of when referring to: * A domain that passed DKIM verification * A domain use by SPF/SenderID to verify that the connection IP is authoriz= ed It seems like you saying there is no need for DKIM or any other authentication system for a domain reputation system. Like I said, I'm lost. > >> -1 billion to using XML > > Why? bloat --=20 Jeff Macdonald Ayer, MA From dotis@mail-abuse.org Tue Aug 10 12:12:01 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 436BC3A695E for ; Tue, 10 Aug 2010 12:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.341 X-Spam-Level: X-Spam-Status: No, score=-106.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 9-yjs+fz1GEf for ; Tue, 10 Aug 2010 12:11:59 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id B17433A67B3 for ; Tue, 10 Aug 2010 12:11:59 -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 503E0A949D4; Tue, 10 Aug 2010 19:12:31 +0000 (UTC) Message-ID: <4C61A49E.7080809@mail-abuse.org> Date: Tue, 10 Aug 2010 12:12:30 -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: Paul Ferguson References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] scope question - what apps? 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, 10 Aug 2010 19:12:01 -0000 On 8/10/10 10:24 AM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Aug 10, 2010 at 9:19 AM, Douglas Otis wrote: > >> On 8/10/10 5:12 AM, Nathaniel Borenstein wrote: >>> How, if at all, should a domain's reputation differ for different >>> protocols? >>> >>> It seems to me that if a domain has been compromised or demonstrated to >>> be antisocial in one context, it is highly likely to be equally >>> untrustworthy in other contexts as well. If that's the case, reputation >>> is very nearly protocol-independent. >>> >>> I certainly believe we should start out focused on email, but we >>> shouldn't rule out the possibility that there's very little that will >>> differ from protocol to protocol, and we should try to avoid being >>> unnecessarily >>> email-specific. >> Nathaniel, >> >> A domain would not be what is compromised, unless perhaps their DNS is. > Hi Doug, > > What about 100% malicious domains? There are literally *thousands* of > domains that have been created by criminals which have no "legitimate" > content, but rather booby-trapped with exploits, malware, etc. > > In fact, there is entire industry (Black Hat SEO) dedicated to drive > traffic (read: unwitting victims) to these domains... Paul, Email represents a store and forward service, where no system directly involved in the distribution of malware or phishing may have been compromised, or the domain identifiers used actually originate from the administrative domain. Taking a simple view should still strive to understand what is an authentic source, and what represents a compromised system. When it comes to email and domains, email is significantly different from other direct services. Some domains are indeed being used extensively for illicit purposes. But an illicit domain being used as desired by the domain owner has not been compromised. As you suggest, these often deal with no legitimate traffic. Another point that might be made is that reputation for such domains often arrives too late. There might be a compromised server within some large enterprise, would you then suggest their entire domain is compromised? Google's safe browser protocol in open source browsers is clearly aimed at addressing phishing and the distribution of malware using http without always impacting an entire domain. When discussing reputation, email is different as it often represents a mixture of sources. Some are from compromised systems that also have a legitimate purpose, where owners of the compromised systems should be notified. In addition, the distribution of malware in email does not mean a providers outbound servers have been compromised. I was attempting to underscore the importance of understanding what it means to have authenticated the domain. In my first message to this list, I said: .--- Irrespective of whether a service attempts to make positive or negative assertions, domain reputation, with a possible exception of malicious content, must relate to the administrative domain running the server and issuing the message. The fundamental criteria for deciding whether a message is abusive relates to whether recipients receive a reasonable level of benefit over that of the sender. In other words, where the message is sent is often more significant than actual content, unless of course the content is blatantly abusive. '--- -Doug From fergdawgster@gmail.com Tue Aug 10 12:18:26 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 92FBB3A683C for ; Tue, 10 Aug 2010 12:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 NSKvf9MF6GwJ for ; Tue, 10 Aug 2010 12:18:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id EBD9A3A6998 for ; Tue, 10 Aug 2010 12:18:23 -0700 (PDT) Received: by wwj40 with SMTP id 40so4476890wwj.13 for ; Tue, 10 Aug 2010 12:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=OVLygwhc4NOju9WLOUPTo26K1RY5pTAN1ZGNpSXaVHg=; b=ICeYf3k33mvM/4KEA0f/eU6DZKWs2ceC3+qG8OaHJXFx25JeogmR6QwkVLGfmxJY0o 1h8t54L7Ooj5JAelrYiLK5hEG2Zn8BtHPUN/f1K/qRCPPEz9Jx3+BlyPWOLjkYfobK82 ckBOkL8r1m89y0hzQGCsmiq2ivRUKs4FsJpkE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=RyU3YQYqI9wEinq29uRdGxzIiNUySfnQKRbg2zJsuTC5jp0TFeV3K6V2mEW4IkXnUF NzIaG4gJIy6bZQwxvMWnUqU24lGphEXtIkSneo2sOfI5Ds7nTur3F/C4TgxcPdtV4lcS VZSx4GsKguyeaeSptFUX/2eSUSbBdqAaRViv4= MIME-Version: 1.0 Received: by 10.216.236.149 with SMTP id w21mr15566177weq.65.1281467938569; Tue, 10 Aug 2010 12:18:58 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 12:18:58 -0700 (PDT) In-Reply-To: <4C61A49E.7080809@mail-abuse.org> References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> Date: Tue, 10 Aug 2010 12:18:58 -0700 Message-ID: From: Paul Ferguson To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] scope question - what apps? 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, 10 Aug 2010 19:18:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The issue for me here is, if you're talking about e-mail *only*, than I can certainly agree that it is worth examination of a way to "authenticate" a domain -- however, I can certainly image domains which could be "authenticated" which still send undesirable traffic (e.g. spam, malware, money mule scams, etc.), and there is already a plethora of solutions in the market to address these issues. Having said that, the issue of "domain reputation" is a tricky one *when not applicable* to e-mail, and this is where the concept is most interesting to me. That is also why I would like to see this discussion focus more on the scope of "domain reputation" -- I don't think limiting this concept to e-mail is actually a big step forward, IMO. $.02, - - ferg On Tue, Aug 10, 2010 at 12:12 PM, Douglas Otis wrote: > On 8/10/10 10:24 AM, Paul Ferguson wrote: >> >> >> Hi Doug, >> >> What about 100% malicious domains? There are literally *thousands* of >> domains that have been created by criminals which have no "legitimate" >> content, but rather booby-trapped with exploits, malware, etc. >> >> In fact, there is entire industry (Black Hat SEO) dedicated to drive >> traffic (read: unwitting victims) to these domains... > > Paul, > > Email represents a store and forward service, where no system directly > involved in the distribution of malware or phishing may have been > compromised, or the domain identifiers used actually originate from the > administrative domain. Taking a simple view should still strive to > understand what is an authentic source, and what represents a > compromised system. When it comes to email and domains, email is > significantly > different from other direct services. > > Some domains are indeed being used extensively for illicit purposes. But > an illicit domain being used as desired by the domain owner has not been > compromised. As you suggest, these often deal with no legitimate > traffic. > Another point that might be made is that reputation for such domains > often arrives too late. > > There might be a compromised server within some large enterprise, would > you then suggest their entire domain is compromised? Google's safe > browser > protocol in open source browsers is clearly aimed at addressing phishing > and the distribution of malware using http without always impacting an > entire domain. > > When discussing reputation, email is different as it often represents a > mixture of sources. Some are from compromised systems that also have a > legitimate purpose, where owners of the compromised systems should be > notified. In addition, the distribution of malware in email does not > mean a providers outbound servers have been compromised. I was > attempting to > underscore the importance of understanding what it means to have > authenticated the domain. > > In my first message to this list, I said: > .--- > Irrespective of whether a service attempts to make positive or negative > assertions, domain reputation, with a possible exception of malicious > content, must relate to the administrative domain running the server and > issuing the message. The fundamental criteria for deciding whether a > message is abusive relates to whether recipients receive a reasonable > level of benefit over that of the sender. In other words, where the > message is sent is often more significant than actual content, unless of > course the content is blatantly abusive. > '--- > -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYaYaq1pz9mNUZTMRAsYNAJ4zfPqcbmjsuF+3fx7FUUFpRl/bKgCfcAnI vnz3ITXWabrit+FzsxJtH5M=3D =3DoOPr -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From jdfalk-lists@cybernothing.org Tue Aug 10 12:30: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 085D43A6AB7 for ; Tue, 10 Aug 2010 12:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3m-iqVFd6ov for ; Tue, 10 Aug 2010 12:30:29 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id E661E3A6AB2 for ; Tue, 10 Aug 2010 12:30:28 -0700 (PDT) Received: from [192.168.11.32] (c-76-126-155-21.hsd1.ca.comcast.net [76.126.155.21]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7AJV1Xo000461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 10 Aug 2010 12:31:03 -0700 References: <20100809202036.80554.qmail@joyce.lan> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 10 Aug 2010 12:31:00 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: [domainrep] authenticated domains & other contexts (was Re: large and small domain reputation) 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, 10 Aug 2010 19:30:31 -0000 On Aug 10, 2010, at 12:08 PM, Jeff Macdonald wrote: > You lost me. A spoofed message with spoofed domains is perfectly > acceptable for input into a domain reputation system? A signing domain in an email message isn't the only reputation context. = There are also reputation systems which consider how likely an HTTP URI = is to be pointing to a phishing site, and these are queried (as = blacklists) by most (perhaps all) modern web browsers. One of the reasons for this pre-WG discussion is to figure out whether = the eventual WG (assuming there will be one) covers multiple contexts. = So far I think it can, but we'll have to be careful to be very clear in = our language. From macfisherman@gmail.com Tue Aug 10 13:02: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 2945A3A67DA for ; Tue, 10 Aug 2010 13:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.151 X-Spam-Level: X-Spam-Status: No, score=-4.151 tagged_above=-999 required=5 tests=[AWL=-1.552, 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 64NxxyxMSQ33 for ; Tue, 10 Aug 2010 13:02:22 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 6FB013A68C5 for ; Tue, 10 Aug 2010 13:02:22 -0700 (PDT) Received: by qyk8 with SMTP id 8so9877805qyk.10 for ; Tue, 10 Aug 2010 13:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6WGOguZpDLt2bQgzvTlU5X1JPH9WvJNmlZ0VWU14kTc=; b=gYvFe0uaceYgL7C678iMYtE5zIghqB2rEmxECIyJiIxWaGWBvVL9z8YRjMlTijRaKw 66TdtdZM+8La5L7cC/7CqcSj1DXVDOX91Eu5SyowMG3KdIN/wh7xwk1Hbhahm+g3Axet vjO2zbEc6zA+WfNU9hwhvOqczowVN8ddxQa7U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rQ+Bv/yNZH/Qe0EzD71VE2fuM7R+3ODEnDGWPzH4W//zq0QeggGRhHIQK9n4jbR2S/ 5ipPcmJ+512uNgniQHdhdivd7PiNXMphKNZMXMbXNuPoGcV9v/fZ2ktz21Y75PK4/3qO 2HcDu9bjU/DudBN6AmhO4mGUKaqxbg+4ufqGk= MIME-Version: 1.0 Received: by 10.224.100.5 with SMTP id w5mr1930709qan.191.1281470577476; Tue, 10 Aug 2010 13:02:57 -0700 (PDT) Received: by 10.229.28.129 with HTTP; Tue, 10 Aug 2010 13:02:57 -0700 (PDT) In-Reply-To: <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> References: <20100809202036.80554.qmail@joyce.lan> <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> Date: Tue, 10 Aug 2010 16:02:57 -0400 Message-ID: From: Jeff Macdonald To: "J.D. Falk" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] authenticated domains & other contexts (was Re: large and small domain reputation) 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, 10 Aug 2010 20:02:25 -0000 On Tue, Aug 10, 2010 at 3:31 PM, J.D. Falk wrote: > On Aug 10, 2010, at 12:08 PM, Jeff Macdonald wrote: > >> You lost me. A spoofed message with spoofed domains is perfectly >> acceptable for input into a domain reputation system? > > A signing domain in an email message isn't the only reputation context. = =A0There are also reputation systems which consider how likely an HTTP URI = is to be pointing to a phishing site, and these are queried (as blacklists)= by most (perhaps all) modern web browsers. > > One of the reasons for this pre-WG discussion is to figure out whether th= e eventual WG (assuming there will be one) covers multiple contexts. =A0So = far I think it can, but we'll have to be careful to be very clear in our la= nguage. Thanks for the clarification J.D. I'm a little confused on how a HTTP URI could be treated the same as a domain. It would seem rather trivial to cause a DoS to Google Docs by hosting some malware on it if the path of the URI wasn't considered too. I like to put out a data point. Food for thought. We often have spam reports for email that we didn't send, yet it contains a URI that we host. Lately these have been the URI of how to add an address to email providers address books. While this doesn't seem to be a big problem today, I can see this type of abuse growing. It isn't much different than an OpenRelay in the sense that some other resource is being used without asking. I suppose this may be out of scope. But I can see simplistic systems in which a message which is deemed abusive penalizes all domains and URIs. We've been forced once to change a host name because it was used in forged email headers. I'd like to think that was a once in a lifetime experience. I'm hoping that whatever comes out of this group we can keep it that way. --=20 Jeff Macdonald Ayer, MA From msk@cloudmark.com Tue Aug 10 13:27:59 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 BE10B3A69B2 for ; Tue, 10 Aug 2010 13:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.571 X-Spam-Level: X-Spam-Status: No, score=-103.571 tagged_above=-999 required=5 tests=[AWL=-0.972, 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 ryid4GgJSOtM for ; Tue, 10 Aug 2010 13:27:57 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 1AEC63A6842 for ; Tue, 10 Aug 2010 13:27:57 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 13:28:32 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 13:28:32 -0700 Thread-Topic: [domainrep] large and small domain reputation Thread-Index: Acs4v3ZjskJpDXK3R6mngNIdJHOWjAACo7pA Message-ID: References: <20100809202036.80554.qmail@joyce.lan> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 20:27:59 -0000 > -----Original Message----- > From: Jeff Macdonald [mailto:macfisherman@gmail.com] > Sent: Tuesday, August 10, 2010 12:09 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] large and small domain reputation >=20 > > So no reputation system may be queried if the message was > > unauthenticated? =A0That seems nonsensical to me. >=20 > You lost me. A spoofed message with spoofed domains is perfectly > acceptable for input into a domain reputation system? Sure. Spam filters and various other security packages do it all the time. > It seems like you saying there is no need for DKIM or any other > authentication system for a domain reputation system. Like I said, I'm > lost. You might select the domain about which you want domain reputation by using= the "d=3D" from DKIM or the domain that was the input to SPF, but is it ap= propriate for a domain reputation protocol definition to stipulate that thi= s is a requirement? > >> -1 billion to using XML > > > > Why? >=20 > bloat But its ubiquity (especially a deployed generate/parse code base) has no va= lue? I think that reasoning is an uphill battle. From msk@cloudmark.com Tue Aug 10 13:31:13 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 1C5B03A6ADE for ; Tue, 10 Aug 2010 13:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=-0.959, 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 xlbeK9ZGfgPT for ; Tue, 10 Aug 2010 13:30:33 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 1B1FC3A6ADC for ; Tue, 10 Aug 2010 13:30:03 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 13:30:38 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 13:30:37 -0700 Thread-Topic: [domainrep] scope question - what apps? Thread-Index: Acs4wOWDHKRMEQhTS7uR6qBxU3HXgwACc5og Message-ID: References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> 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] scope question - what apps? 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, 10 Aug 2010 20:31:13 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Paul Ferguson > Sent: Tuesday, August 10, 2010 12:19 PM > To: Douglas Otis > Cc: domainrep@ietf.org > Subject: Re: [domainrep] scope question - what apps? >=20 > That is also why I would like to see this discussion focus more on the > scope of "domain reputation" -- I don't think limiting this concept to > e-mail is actually a big step forward, IMO. I agree, and that's why I think there may well be a variety of different do= main reputation vendors: email signers, web URLs, etc. I think we should t= ry to cater to all of those by staying as generic as possible. From dhc@dcrocker.net Tue Aug 10 13:51:47 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 C9F473A67B1 for ; Tue, 10 Aug 2010 13:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 XdSFwfvyrZ0z for ; Tue, 10 Aug 2010 13:51:45 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 4C81428C0E3 for ; Tue, 10 Aug 2010 13:51:45 -0700 (PDT) Received: from [192.168.1.116] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7AKqEk1030834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Aug 2010 13:52:20 -0700 Message-ID: <4C61BBFB.5050102@dcrocker.net> Date: Tue, 10 Aug 2010 13:52:11 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: domainrep@ietf.org References: <20100809202036.80554.qmail@joyce.lan> <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> In-Reply-To: <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Aug 2010 13:52:20 -0700 (PDT) Subject: [domainrep] reputation scope X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:51:47 -0000 On 8/10/2010 12:31 PM, J.D. Falk wrote: > A signing domain in an email message isn't the only reputation context. > There are also reputation systems which consider how likely an HTTP URI is to > be pointing to a phishing site, and these are queried (as blacklists) by most > (perhaps all) modern web browsers. > > One of the reasons for this pre-WG discussion is to figure out whether the > eventual WG (assuming there will be one) covers multiple contexts. So far I > think it can, but we'll have to be careful to be very clear in our language. I send email. I have a web site. These might entail two (or more) reputations or might entail one. Ignoring the question of granularity, for the moment -- that is, different classes of information stream, such as personal mail from invoices -- is it reasonable and useful to group my reputation under a single score? So, should the reputation for mail from bbiw.net be the same as for http://bbiw.net? I think it should. Or more specifically, I think that the service (mail vs. web) is not as important as the content type (personal vs invoice vs marketing vs...). I could argue this the other way, but mostly I think that distinguishing between media is a gradation that isn't helpful. This entire game is pretty coarse-grained, so distinctions should be made only when the pertain to likely differences in reputation that will be major. I suggest that differential reputations should /only/ pertain to differences in content type (in the social sense, not the mime sense) and not with the means by which the content is conveyed. Thoughts? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Tue Aug 10 16:10: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 262EB3A696D for ; Tue, 10 Aug 2010 16:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.588 X-Spam-Level: X-Spam-Status: No, score=-108.588 tagged_above=-999 required=5 tests=[AWL=0.752, BAYES_20=-0.74, 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 2TmPv5m9sdAE for ; Tue, 10 Aug 2010 16:10:46 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 078E83A68C5 for ; Tue, 10 Aug 2010 16:10:45 -0700 (PDT) Received: (qmail 59686 invoked from network); 10 Aug 2010 23:11:20 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 10 Aug 2010 23:11:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:cc:mime-version:content-type:content-transfer-encoding; s=k1008; olt=johnl@user.iecc.com; bh=+tDzTVFj6HEn4SrGfZ1e6oIQ3InHZbt9Ys3MlVYWmuc=; b=QAPnrEuMAubrHAcw5y/m3D0PiikYPfdSqNG49gAk9V/vB4PEklZcR1UyFd13mJhiWMdEx2lkQocAxAgsqC8gdIO+UOXNnkWVvN2tgjAS0B23qipT6OtlITo2j7hi3VdQ0OKPjA2FWLEonGFEH+2uqJNILuoMbmrqrxIdHOeYwcw= Date: 10 Aug 2010 23:11:19 -0000 Message-ID: <20100810231119.71971.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: [domainrep] A sketch of a small query reputation system 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, 10 Aug 2010 23:10:48 -0000 Let's say you have a domain dubious.example, and you want to ask scorekeeper.example what its reputation is. You do a DNS lookup of dubious.example._rep.scorekeeper.example Maybe it's a TXT record, maybe it's a new RR type. If scorekeeper.example has an opinion about dubious.example, it returns a record with three numbers it it. Perhaps they're space separated digit strings in a TXT record, or three fields in a REPUTATION record. They are: Quality of domain: 0-99 with 99 being the best Confidence of opinion: 0-99 with 99 being most certain NAICS code: up to six digits, 0 if unknown, describing the type of organization Note that NAICS is sort of like Dewey decimal, with longer numbers being subclasses of shorter ones, so 92 is any government body, 922120 is a police department, 52 is a financial institution, 5221 is a bank, 522110 is a commercial bank, and 522130 is a credit union. If you want to publish different opinions for different kinds of domain usage, you give them separate names, e.g. dubious.example._rep.mail.scorekeeper.example dubious.example._rep.web.scorekeeper.example R's, John From johnl@iecc.com Tue Aug 10 16:18: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 36CB53A6964 for ; Tue, 10 Aug 2010 16:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.536 X-Spam-Level: X-Spam-Status: No, score=-109.536 tagged_above=-999 required=5 tests=[AWL=1.663, 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 qRZ6gT9eMWZb for ; Tue, 10 Aug 2010 16:18:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id DC8B43A68A7 for ; Tue, 10 Aug 2010 16:18:30 -0700 (PDT) Received: (qmail 62648 invoked from network); 10 Aug 2010 23:19:06 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 10 Aug 2010 23:19:06 -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=k1008; olt=johnl@user.iecc.com; bh=0HhJSkvPD179lmHP70tTTP18qDjynCoaNmSY6+4yB18=; b=UrlEgRjJ2qEDksd/k21YNexR9qfPlr5OKd5i5dhuN5yfOt2WtYOkyGdVCzAA0sAbP1WV0ezTxXL50tRgTE24Mnv0syXF3AOx+KVOzTh13OO7DFzAdz0qomE8qsTuKzDKWR8VU5E8v0tL44dI7T1O85ePw7Lns+v4ogOFM/jm4tY= Date: 10 Aug 2010 23:19:06 -0000 Message-ID: <20100810231906.73864.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <051948C7-5D1C-4B3B-9510-9F2D37EB426C@cybernothing.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] large and small domain reputation 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, 10 Aug 2010 23:18:32 -0000 > I can't imagine any way that a cooperative distributed open database >could be useful -- simply because it'd be attacked constantly by >people who want to (ahem) change their reputation. Perhaps someone from Cloudmark could say how well Vipul's Razor managed to deal with that problem. It's the openest rep system I can think of. >For a standards discussion, however, shouldn't we be >implementor-agnostic and try to create a protocol that can work for >both the CDOD and the vendors, within reason? It might be useful to spec something that organizations who already know each other could use to exchange rep data, although it's not immediately obvious why you'd need anything more than the ability to query each other's database. R's, John From dotis@mail-abuse.org Tue Aug 10 17:07:47 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 014EF3A69B6 for ; Tue, 10 Aug 2010 17:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.347 X-Spam-Level: X-Spam-Status: No, score=-106.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 QXUuzKSdwoya for ; Tue, 10 Aug 2010 17:07:45 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id E3E813A69B4 for ; Tue, 10 Aug 2010 17:07:42 -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 1C42AA94502 for ; Wed, 11 Aug 2010 00:08:13 +0000 (UTC) Message-ID: <4C61E9EC.5030500@mail-abuse.org> Date: Tue, 10 Aug 2010 17:08:12 -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: <20100810231119.71971.qmail@joyce.lan> In-Reply-To: <20100810231119.71971.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 00:07:47 -0000 On 8/10/10 4:11 PM, John Levine wrote: > Let's say you have a domain dubious.example, and you want to ask > scorekeeper.example what its reputation is. You do a DNS lookup of > > dubious.example._rep.scorekeeper.example > > Maybe it's a TXT record, maybe it's a new RR type. If scorekeeper.example > has an opinion about dubious.example, it returns a record with three > numbers it it. Perhaps they're space separated digit strings in a TXT > record, or three fields in a REPUTATION record. They are: > > Quality of domain: 0-99 with 99 being the best > > Confidence of opinion: 0-99 with 99 being most certain > > NAICS code: up to six digits, 0 if unknown, describing the type of > organization > > Note that NAICS is sort of like Dewey decimal, with longer numbers > being subclasses of shorter ones, so 92 is any government body, 922120 > is a police department, 52 is a financial institution, 5221 is a bank, > 522110 is a commercial bank, and 522130 is a credit union. > > If you want to publish different opinions for different kinds of > domain usage, you give them separate names, e.g. > > dubious.example._rep.mail.scorekeeper.example > > dubious.example._rep.web.scorekeeper.example John, Does this approach assume scorekeeper.example uses wildcard expansion to capture random sub-domains used by bad actors at high rates? What is the result when scorekeeper.example does not respond before a DNS timeout? What is the result when scorekeeper.example returns no answer for a domain being queried? How does scorekeeper.example score content for a user's web content, without also having this score applied against other web pages? What NAICS like number will scorekeeper.example use for domains lacking ownership details? Shouldn't scorekeeper.example return an epoch time for the period a domain belongs to the same owner? How does scorekeeper.example defend their service from abusive clients? -Doug From stephen.farrell@cs.tcd.ie Tue Aug 10 17:10:22 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 B6F9A3A6966 for ; Tue, 10 Aug 2010 17:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.985 X-Spam-Level: X-Spam-Status: No, score=-102.985 tagged_above=-999 required=5 tests=[AWL=-0.386, 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 HcS6-V5Do5uJ for ; Tue, 10 Aug 2010 17:10:21 -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 06B0D3A67E1 for ; Tue, 10 Aug 2010 17:10:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 257EA3E407C; Wed, 11 Aug 2010 01:10:54 +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=1281485454; bh=lzt1Z2iUUnzo1C JENyP4HZA6CQBLCEuiMRe3VQ+urU0=; b=VCouv6xIST2H0EP3lCMkhsPUd2kgTo ar6wJ0Wr7rz+NeJvje/Vxp3r66CYqCh2lDZOO55OTHj4OyspCTUpw5o64HlR1dnK eiG3ETVcpU6OasZAAzWqFIIaVVX4IOsO8O2Jf8QZOMfJ2sruv+EC7t45Dx9887wF 1XdBBTKEj1eyS3f37oxlSy+V6wGG7pK3i180TqvC0cK8+Am0kGwiQUUdC2JJE/eg ycRaOXJ1GwV67Q+q5LLBZDnjOXCtCKHt0lN4OeOpgU5uanXyUJR4kNwfJEfl0Jt0 eKJr4YKHRV+TKrw82ojF9VE8xw/yW0VjuFtd2KRwKKMGc2yzxV+kCLug== 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 SLvI8K+wGz4F; Wed, 11 Aug 2010 01:10:54 +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 C30F83E4079; Wed, 11 Aug 2010 01:10:53 +0100 (IST) Message-ID: <4C61EA85.5080707@cs.tcd.ie> Date: Wed, 11 Aug 2010 01:10:45 +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: John Levine References: <20100810231119.71971.qmail@joyce.lan> In-Reply-To: <20100810231119.71971.qmail@joyce.lan> 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] A sketch of a small query reputation system 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, 11 Aug 2010 00:10:22 -0000 On 11/08/10 00:11, John Levine wrote: > NAICS code: up to six digits, 0 if unknown, describing the type of > organization Eh... what does the NA stand for there? (He asked rhetorically, having just looked it up:-) Fair enough that its a sketch but are you really proposing a *regional* encoding of the type of *industry* as an abstract way of classifying domain reputation? Seems like a bad idea to me I have to say. S. From ietf-dkim@kitterman.com Tue Aug 10 17:17:19 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 2A3C93A69D3 for ; Tue, 10 Aug 2010 17:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.407 X-Spam-Level: X-Spam-Status: No, score=-4.407 tagged_above=-999 required=5 tests=[AWL=-1.808, 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 XjglyaJpbq97 for ; Tue, 10 Aug 2010 17:17:10 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id BF98C3A69E9 for ; Tue, 10 Aug 2010 17:17:00 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 2ADC238C0B3; Tue, 10 Aug 2010 20:17:35 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1281485855; bh=YvIpM2H+A8EibnYgn2BjDLBiYkUSsJOlWZQgPbksvL8=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=f3BI2afA87p/aoLglE6WqPAEmVwW3oqBW8jqJ5sex4HdMpgmK7gUsixAfPSwuABcq K7XmOEFhYapwWPLjzO6nTtbjCWdT70eX0tkiWy+6DAvZ1wIxAwl2NOvrrG6z1kWwWw PY7s5ehpO9NmYJIzRmT4InxqffUV+OL+rWYpqO8A= From: Scott Kitterman To: domainrep@ietf.org Date: Tue, 10 Aug 2010 20:17:33 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> In-Reply-To: <4C61EA85.5080707@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008102017.34211.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 00:17:19 -0000 On Tuesday, August 10, 2010 08:10:45 pm Stephen Farrell wrote: > On 11/08/10 00:11, John Levine wrote: > > NAICS code: up to six digits, 0 if unknown, describing the type of > > > > organization > > Eh... what does the NA stand for there? (He asked rhetorically, > having just looked it up:-) > > Fair enough that its a sketch but are you really proposing a > *regional* encoding of the type of *industry* as an abstract > way of classifying domain reputation? Seems like a bad idea to > me I have to say. Perhaps NAICS isn't the best tool to use, but I do find the idea of what type of organization the domain is believed to represent is a useful data point to include. I've done some analysis work in this area and for scalar reputation scoring, the value I would consider "Good" or "Bad" is different depending on the type of entity. "Good" for a free webmail provider might well be "Bad" for a bank. Scott K From stephen.farrell@cs.tcd.ie Tue Aug 10 17:17:37 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 E193D3A6966 for ; Tue, 10 Aug 2010 17:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.937 X-Spam-Level: X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.337, 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 IcGJCOHnBXXX for ; Tue, 10 Aug 2010 17:17:37 -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 B28703A69E9 for ; Tue, 10 Aug 2010 17:17:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id C910C3E407C; Wed, 11 Aug 2010 01:18:10 +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=1281485890; bh=OaMwwZczlOsVqk GXX4jAcsHoefvZDXSPzfY77tDe0Rk=; b=y6CxLramt4dVZWUhRFa7FvExFzvO7t r30AvdkuZTFaa3DFcfUu8enoMRwi3i2vmpPlHtIPXwB0ViAPkECGCcYQLtLL4a3G FPkkxnVbyrpW748EwaD5HyEpL81e3/rSiFMgT0uTqLF3Y7/oPjrvOZ875s3YtyPe AwVxdLd8ZwcnIHYBGuFIIDLILGqwdVMbBPYRrEPWlmUmClbWj8iYvVz5dvAjkkk4 jLTT9EjjjXXIj0YDdOCv3vy2qwaaejyixDxpHgsR824KcYXTMBNrr5Z1c6dGyB4k l4Fqf7qACFSBYHl7Q94FDR4hPBx51B/6B5usAhnAAOI6EKaToEcXBFag== 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 7VZ0M+SYubpu; Wed, 11 Aug 2010 01:18:10 +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 5D9E63E4079; Wed, 11 Aug 2010 01:18:10 +0100 (IST) Message-ID: <4C61EC40.1050202@cs.tcd.ie> Date: Wed, 11 Aug 2010 01:18:08 +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: dcrocker@bbiw.net References: <20100809202036.80554.qmail@joyce.lan> <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> <4C61BBFB.5050102@dcrocker.net> In-Reply-To: <4C61BBFB.5050102@dcrocker.net> 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] reputation scope 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, 11 Aug 2010 00:17:38 -0000 On 10/08/10 21:52, Dave CROCKER wrote: > I think it should. Or more specifically, I think that the service (mail > vs. web) is not as important as the content type (personal vs invoice vs > marketing vs...). Interesting idea. What if you wanted to judge the reputation of the coffee shop wifi supplier? Doesn't seem to easily map to a content type. But maybe we really shouldn't have this effort look below the transport layer. > I could argue this the other way, [...] I see what you mean. Me too. I'm not sure where I'd land on the service vs. content type choice. S. From fergdawgster@gmail.com Tue Aug 10 17: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 BC79C3A67A5 for ; Tue, 10 Aug 2010 17:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 5WbPmHAZpu7Y for ; Tue, 10 Aug 2010 17:26:06 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 864193A67A4 for ; Tue, 10 Aug 2010 17:26:06 -0700 (PDT) Received: by wyb40 with SMTP id 40so12513381wyb.31 for ; Tue, 10 Aug 2010 17:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=znL8tm8pASb+MfSUOiMbw5PjMVuTvl1tecFHaeE0G5A=; b=wYgAsXKeh0EVjvAtDU142P6tQe60Bi2aiE+B+6tXY6e3Fm7+3WJxvzXvy816OLXnUh vnCYIzahrh8nSNY6lHx7doS+pAlpVpZjCW1JtxDbYUZ0q2lmxQSrZYFPdi/GkVGhpMjc AfawjXPU7pkFGtUhWXASBNYE5U8RkF1IKQOWU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s11xojRoVyRALOrawVHLLhw74I92OBiGTWjmFGQOhFl0teLJh36cEvAQnodYDzmLX5 U9U6dJRDljzGY5fs35ed4sEAFReHYhIeg4YfjoZGRmBB2/l9/wDDRzpxwKUqIa7e2AnW tAkART5I7aL8TsNiSEKFjlSdT1vFxl3wXKSvE= MIME-Version: 1.0 Received: by 10.216.1.17 with SMTP id 17mr4524846wec.99.1281486401384; Tue, 10 Aug 2010 17:26:41 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 17:26:41 -0700 (PDT) In-Reply-To: <201008102017.34211.ietf-dkim@kitterman.com> References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> Date: Tue, 10 Aug 2010 17:26:41 -0700 Message-ID: From: Paul Ferguson To: Scott Kitterman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 00:26:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 5:17 PM, Scott Kitterman wrote: > Perhaps NAICS isn't the best tool to use, but I do find the idea of what > type of organization the domain is believed to represent is a useful data > point to include. I've done some analysis work in this area and for > scalar reputation scoring, the value I would consider "Good" or "Bad" is > different depending on the type of entity. "Good" for a free webmail > provider might well be "Bad" for a bank. > Exactly. A scalar reputation scoring is absolutely necessary, I would think. And in fact, it would let the user of the service determine their own "levels of badness" (or "levels of goodness") at the local level. - - ferg p.s I also noticed that you created (or presumably already had one) a separate e-mail address (ietf-dkim@) for this list, which again compels me to state that tying domain reputation *only* to e-mail/dkim/spf/whatever issues is a very bad idea. -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYe47q1pz9mNUZTMRApHsAKDEo9Vj4VrNISw0lMA/Y9ogOwnnygCfcHH9 61B6s+Y2wrQHCkohq3zZhIo=3D =3De4qA -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From dotis@mail-abuse.org Tue Aug 10 18:08:19 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 450823A6881 for ; Tue, 10 Aug 2010 18:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.195 X-Spam-Level: X-Spam-Status: No, score=-106.195 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, 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 R23lskUQ-1pO for ; Tue, 10 Aug 2010 18:08:18 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id F34553A67A5 for ; Tue, 10 Aug 2010 18:08:17 -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 C0D9EA9461B for ; Wed, 11 Aug 2010 01:08:51 +0000 (UTC) Message-ID: <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 18:08:51 -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: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 01:08:19 -0000 On 8/10/10 5:26 PM, Paul Ferguson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, Aug 10, 2010 at 5:17 PM, Scott Kitterman > wrote >> Perhaps NAICS isn't the best tool to use, but I do find the idea of what >> type of organization the domain is believed to represent is a useful data >> point to include. I've done some analysis work in this area and for >> scalar reputation scoring, the value I would consider "Good" or "Bad" is >> different depending on the type of entity. "Good" for a free webmail >> provider might well be "Bad" for a bank. > Exactly. A scalar reputation scoring is absolutely necessary, I would > think. > > And in fact, it would let the user of the service determine their own > "levels of badness" (or "levels of goodness") at the local level. > > - - ferg > > p.s I also noticed that you created (or presumably already had one) a > separate e-mail address (ietf-dkim@) for this list, which again compels me > to state that tying domain reputation *only* to e-mail/dkim/spf/whatever > issues is a very bad idea. Paul, What works for email does not work for web traffic, unless the goal is to completely exclude a domain from being resolved within any type of exchange. Having a millions of users walking your version of the dns name tree represent a fairly susceptible approach. See: http://www.theregister.co.uk/2010/08/09/dns_service_monster_ddos/ There is a different approach that might better achieves these goals when dealing with the worst of the worst. ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt -Doug From fergdawgster@gmail.com Tue Aug 10 18:16:34 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 BAD1E3A69E1 for ; Tue, 10 Aug 2010 18:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ZYwWNAo748Zy for ; Tue, 10 Aug 2010 18:16:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 48EA23A6965 for ; Tue, 10 Aug 2010 18:16:33 -0700 (PDT) Received: by wwj40 with SMTP id 40so4761027wwj.13 for ; Tue, 10 Aug 2010 18:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FYPi8SHo85mGrGj94MpkugtXOIabXEJxww3cR9q/RbE=; b=iIY9Hm1RYtRpuhAzV8YQ6ZGJ1srLIDbrE+TzgDtTvBEa6x/NwTNT/4AV1sJF5jf8uI uo95HxI838Lurm/yFh4xpyA11tmflBZhJHpHFh2JI/JNvGb9rIZqm1G1B51t/RxFjL96 INRAVUf+YxTTnjqiUPfpU8lQ5KtbS5x9lCdGo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TYvVSvw+1La0gs0zltkdr9J4TXzztv47cE8uSODD+pJ3B/m+YhBN/nuqChHeDyq1SD ssJKiAI/N8xGq82DBwgQxfTpVj2ngob9GW4KxW+b4ZuB9zXKO7TExXwfppiiPoqlLl2P WeWVl6UTZ97e4MT0bL7DfVwaY26Kxi1DRiKJA= MIME-Version: 1.0 Received: by 10.216.3.19 with SMTP id 19mr4549290weg.108.1281489428284; Tue, 10 Aug 2010 18:17:08 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 18:17:08 -0700 (PDT) In-Reply-To: <4C61F823.8090207@mail-abuse.org> References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 18:17:08 -0700 Message-ID: From: Paul Ferguson To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 01:16:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 6:08 PM, Douglas Otis wrote: > > There is a different approach that might better achieves these goals when > dealing with the worst of the worst. > > ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt > Hi Doug, Yes, I'm fully aware of DNS RPZ -- that is *one* approach to an *implementation* of "domain reputation" -- there are certainly many others which do not use DNS as the methodology (which I expect will be the most contentious part of the entire proposal). The point I'm trying to make -- and probably not too well -- is that the scope of "domain reputation" is all over the map right now, and I urge participants of this mailing list to not pigeon-hole "domain reputation" to strictly an e-mail -centric issue. Otherwise, I fear this effort will fail just as miserably as other e-mail "reputation" systems that have come out of the IETF, with regards to solving a real problem. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYfoKq1pz9mNUZTMRAiIHAKCl3hsNbpLMwPQ9zshxINshtCFLIgCg5mUJ SkB6MAWX0cdxAzicQMnTQE8=3D =3DpGV6 -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From ietf-dkim@kitterman.com Tue Aug 10 18:20:11 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 63CA73A683E for ; Tue, 10 Aug 2010 18:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.268 X-Spam-Level: X-Spam-Status: No, score=-4.268 tagged_above=-999 required=5 tests=[AWL=-1.669, 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 JJZLa-bazY8d for ; Tue, 10 Aug 2010 18:20:10 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id F21CF3A67A5 for ; Tue, 10 Aug 2010 18:20:09 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 0C70938C0B3; Tue, 10 Aug 2010 21:20:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1281489645; bh=imYtkqtlNGBwuoHnA/8kIntFEnhsCKcPSCuhIco1TMk=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=TdvzG+HC3YLvTuy9soCZog+ahbVytZE+X2MXXmT/BOP3zh1zcd3vRfV6LaFThkuAN L4hJuQk69vVU6uTcrYEI+xo8TQ89SI3xxcJK3QJCT5kSFv1Ji2UcSCzjv8LjHsR1iR 6gJ/dsInc83YE+8/4vJfNWs1ljDs6FG60FsqvfSQ= From: Scott Kitterman To: domainrep@ietf.org Date: Tue, 10 Aug 2010 21:20:44 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <20100810231119.71971.qmail@joyce.lan> <201008102017.34211.ietf-dkim@kitterman.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008102120.44811.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 01:20:11 -0000 On Tuesday, August 10, 2010 08:26:41 pm Paul Ferguson wrote: > p.s I also noticed that you created (or presumably already had one) a > separate e-mail address (ietf-dkim@) for this list, which again compels me > to state that tying domain reputation *only* to e-mail/dkim/spf/whatever > issues is a very bad idea. Don't read too much into it. Scott K From johnl@iecc.com Tue Aug 10 19:12:46 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 A015C3A6894 for ; Tue, 10 Aug 2010 19:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.561 X-Spam-Level: X-Spam-Status: No, score=-109.561 tagged_above=-999 required=5 tests=[AWL=1.638, 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 ggaOduWFxmKD for ; Tue, 10 Aug 2010 19:12:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 3A7633A67ED for ; Tue, 10 Aug 2010 19:12:43 -0700 (PDT) Received: (qmail 30022 invoked from network); 11 Aug 2010 02:13:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=3fQc6BDTV09+49+WaAgkYIZyAMEYCxvqheRRaxzjIB0=; b=xtb/o4lYkCnw2wsehWVcRSGym3dFya4Yh0eawEE/qDKaz9Chj2YHul2+AVXCgQIHbzJNeMr3zl52IwzrE7KNBJrW58EPrdm7GHwKzdrRd7Z/p+zav2bcC/jyyFbgfdF8VCueCVRofnfNm4TYYJJEoI5DH8gYpJ1IsPJ0UQfhIOc= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 02:12:55 -0000 Date: 10 Aug 2010 22:13:17 -0400 Message-ID: From: "John R. Levine" To: "Stephen Farrell" In-Reply-To: <4C61EA85.5080707@cs.tcd.ie> References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 02:12:46 -0000 > Eh... what does the NA stand for there? (He asked rhetorically, > having just looked it up:-) > > Fair enough that its a sketch but are you really proposing a > *regional* encoding of the type of *industry* as an abstract > way of classifying domain reputation? Seems like a bad idea to > me I have to say. I want some way to say "this is a bank" and as many other kind of organizations as possible, without reinventing this wheel. It's true, NAICS is managed by the US census bureau, but so what? I'm not aware of any other coding scheme that's as widely used. If there is one, I'm happy to use that instead. R's, John From dhc@dcrocker.net Tue Aug 10 20:11:33 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 4507A3A699E for ; Tue, 10 Aug 2010 20:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 vtbHBVEdQ3bK for ; Tue, 10 Aug 2010 20:11:31 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 5F6AC3A6910 for ; Tue, 10 Aug 2010 20:11:31 -0700 (PDT) Received: from [192.168.1.120] (ppp-68-122-73-240.dsl.pltn13.pacbell.net [68.122.73.240]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o7B3Bxj3016781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Aug 2010 20:12:04 -0700 Message-ID: <4C6214FB.6070806@dcrocker.net> Date: Tue, 10 Aug 2010 20:11:55 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Stephen Farrell References: <20100809202036.80554.qmail@joyce.lan> <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> <4C61BBFB.5050102@dcrocker.net> <4C61EC40.1050202@cs.tcd.ie> In-Reply-To: <4C61EC40.1050202@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 10 Aug 2010 20:12:04 -0700 (PDT) Cc: domainrep@ietf.org Subject: Re: [domainrep] reputation scope X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: dcrocker@bbiw.net List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 03:11:33 -0000 On 8/10/2010 5:18 PM, Stephen Farrell wrote: > I see what you mean. Me too. I'm not sure where I'd land on the service > vs. content type choice. On further reflection, I realized that even what I appeared to be suggesting -- and possibly /was/ suggesting -- moves towards a multivariate labeling method -- name plus some attributes -- for accessing a particular reputation. And that's exactly what I /don't/ want to recommend. I'd like to see a basic model that uses only a single value, namely the name. If a name owner wants to differentiate reputations, use different names. That's why some deity invented sub-domains. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From fergdawgster@gmail.com Tue Aug 10 20:25:26 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 0C3CD3A68DD for ; Tue, 10 Aug 2010 20:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 G43vBjz+sQva for ; Tue, 10 Aug 2010 20:25:24 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B66823A6767 for ; Tue, 10 Aug 2010 20:25:23 -0700 (PDT) Received: by wyb40 with SMTP id 40so12658321wyb.31 for ; Tue, 10 Aug 2010 20:25:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5K6S5XzmUtmbY9CckgO1A6d7j9XzGXDMFdh4hNnR+6o=; b=sBEiGIKY4MfF1hGj8Hqxqw9E3q46o8mCzC/n1LuxXQf1R7by1V+ZfmgjQOfqPpbhCL bTqOcQIp5SNyDWSDXA5tIyfw5AvgJGwG8ljFSWk/95wLTZlcgn3sYRCrhY/0TZpM05YC uFd/XcDc9aoPnTsjBIHzRGfoSCijSF+mzxjSQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=t+8bVzZDtzCWoa08B+a/DxPbh9o2/rLD4r6xiGeHyFd3Wb0hOwsGJdjdBAXEyKQSOT jK2Cg8ywQ4WMg5DZBvOmjhKX7IeFKwNR4U8za06ZJP5HDz2iv4lSQrd1iqErb4t6IiEQ qASSmb0VIBJkV4boNC/0spgF7NZuN15Aw7pvU= MIME-Version: 1.0 Received: by 10.216.182.202 with SMTP id o52mr16059422wem.29.1281497158643; Tue, 10 Aug 2010 20:25:58 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 20:25:58 -0700 (PDT) In-Reply-To: <4C6214FB.6070806@dcrocker.net> References: <20100809202036.80554.qmail@joyce.lan> <24CF3C1E-B259-4159-B2ED-0419E3C58B71@cybernothing.org> <4C61BBFB.5050102@dcrocker.net> <4C61EC40.1050202@cs.tcd.ie> <4C6214FB.6070806@dcrocker.net> Date: Tue, 10 Aug 2010 20:25:58 -0700 Message-ID: From: Paul Ferguson To: dcrocker@bbiw.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] reputation scope 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, 11 Aug 2010 03:25:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 8:11 PM, Dave CROCKER wrote: > > > On 8/10/2010 5:18 PM, Stephen Farrell wrote: >> >> I see what you mean. Me too. I'm not sure where I'd land on the service >> vs. content type choice. > > > On further reflection, I realized that even what I appeared to be > suggesting -- and possibly /was/ suggesting -- moves towards a > multivariate labeling method -- name plus some attributes -- for > accessing a particular > reputation. > > And that's exactly what I /don't/ want to recommend. I'd like to see a > basic model that uses only a single value, namely the name. If a name > owner wants to differentiate reputations, use different names. That's > why some deity invented sub-domains. > Hi Dave, Again, I'm not even sure what you mean. Are you talking about e-mail w.r.t. domains? We have a specific logic which understands how to "cascade" both up (to subdomains in a URI) and down (to a URL path). This is certainly easy to define in the public domain (e.g. IETF or elsewhere). Again, I'm sorry if I misunderstand your point, but subdomains shouldn't be any real problem whatsoever with the properly specified logic and signifiers (e.g. wildcards, other special characters, etc). Also (and again), I'm trying to widen this issue to "domains" w.r.t. web threats, not e-mail. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYhhAq1pz9mNUZTMRAjyEAKC51jjRGuuEMd93yZmAbDJg3DWH0gCfXE3p b1PADruue96WBM5HzDBymAo=3D =3D8GXA -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 21:30:33 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 7B87A3A69D7 for ; Tue, 10 Aug 2010 21:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=-0.947, 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 nU0ZLmUD7FCB for ; Tue, 10 Aug 2010 21:30:30 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 267433A67B4 for ; Tue, 10 Aug 2010 21:30:30 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 Aug 2010 21:31:05 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 21:31:04 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs4+smHsxwecN9GRfS+EPh7hrEqwwAEykaQ Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 11 Aug 2010 04:30:34 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of John R. Levine > Sent: Tuesday, August 10, 2010 7:13 PM > To: Stephen Farrell > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > I want some way to say "this is a bank" and as many other kind of > organizations as possible, without reinventing this wheel. >=20 > It's true, NAICS is managed by the US census bureau, but so what? I'm > not > aware of any other coding scheme that's as widely used. If there is > one, > I'm happy to use that instead. Is an IANA registry a crazy idea? From fergdawgster@gmail.com Tue Aug 10 21:32:14 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 ADEFB3A680F for ; Tue, 10 Aug 2010 21:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ut45IKkvf1ak for ; Tue, 10 Aug 2010 21:32:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id B6EF53A67B4 for ; Tue, 10 Aug 2010 21:32:10 -0700 (PDT) Received: by wyb40 with SMTP id 40so12706071wyb.31 for ; Tue, 10 Aug 2010 21:32:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Mm4acuPSjaXTQNO3oJgi35S2C3pnIVyywFfp4y3G/bc=; b=u6L7DR1c1KR9hJ347zyw0Xwe+P9RosVw5HqPwx1/x0SxWq+qxJn29xNLlxRWUVRd3O SER/h02fgnJ4qCZNOwlj8ghXdEPp/hgcQViWLkjtUyuZG7g3KgxXawbVG9Xy/qW1d/NJ TwIkXmR4xeer3LBfbFmhKvsNBhrRfTvMV0PZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ub/TxKSJVBTRo4GWEIhO1hb2L9uWW+KMyiPLzO8qYMKL9eoczopflDYIXCt8pjhpwl etsi796B0o6awKGBMOZKFZkwAdApG0qVxpNG2wWgxOrxkgYvuTaAzONTz4lGgSQTJZuG A0YhlZlxfwv0yUwiKv96voQeUuceJrOLnJKDU= MIME-Version: 1.0 Received: by 10.216.28.213 with SMTP id g63mr4751205wea.71.1281501165756; Tue, 10 Aug 2010 21:32:45 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 21:32:45 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> Date: Tue, 10 Aug 2010 21:32:45 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:32:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 9:31 PM, Murray S. Kucherawy wrote: > > Is an IANA registry a crazy idea? Perhaps, yes. Registry for what, exactly? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYifoq1pz9mNUZTMRAk5RAKDG29A6X+nDPTyr8GwE1LMmPDYVSQCePWTt jtOrdYYD16GlsMpTqfm0Q+c=3D =3Dm7la -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 21: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 5A03E3A67B4 for ; Tue, 10 Aug 2010 21:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=-0.935, 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 G6IQ+wwsecwV for ; Tue, 10 Aug 2010 21: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 31E303A680F for ; Tue, 10 Aug 2010 21: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; Tue, 10 Aug 2010 21:33:53 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 21:33:52 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5DkAWC190ArD1TuKL6GPOKJTW1wAABgqA Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:33:23 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 9:33 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > > Is an IANA registry a crazy idea? >=20 > Perhaps, yes. >=20 > Registry for what, exactly? As a non-North-American-centric registry for business types. From msk@cloudmark.com Tue Aug 10 21:36: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 BF27B3A69D5 for ; Tue, 10 Aug 2010 21:36:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.522 X-Spam-Level: X-Spam-Status: No, score=-103.522 tagged_above=-999 required=5 tests=[AWL=-0.923, 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 MiHAdPDXE2iB for ; Tue, 10 Aug 2010 21:36:23 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id E2AD93A699E for ; Tue, 10 Aug 2010 21:36:23 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 Aug 2010 21:36:59 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 21:36:58 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs48uz6WTYm1U8/S2ma3mt/Y45+DwAG6cgA Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> 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] A sketch of a small query reputation system 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, 11 Aug 2010 04:36:24 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Paul Ferguson > Sent: Tuesday, August 10, 2010 6:17 PM > To: Douglas Otis > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > The point I'm trying to make -- and probably not too well -- is that > the > scope of "domain reputation" is all over the map right now, and I urge > participants of this mailing list to not pigeon-hole "domain > reputation" to > strictly an e-mail -centric issue. Actually I think John's proposal deals with this reasonably well. A reputa= tion vendor has the option of publishing reputation data about a domain at = _rep.example, or subdividing the domain to be targeted toward various appli= cations (_rep.mail.example, _rep.web.example, etc.). Clients can query acc= ordingly. Trepidations about using the DNS aside, that seems pretty robust to me. > Otherwise, I fear this effort will fail just as miserably as other e- > mail > "reputation" systems that have come out of the IETF, with regards to > solving a real problem. Are you referring to RBLs, or something else I'm not aware of? From fergdawgster@gmail.com Tue Aug 10 21:37:47 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 88CDE3A69D7 for ; Tue, 10 Aug 2010 21:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_31=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 S4RNQxJW-qvn for ; Tue, 10 Aug 2010 21:37:46 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 75D123A699E for ; Tue, 10 Aug 2010 21:37:46 -0700 (PDT) Received: by wwj40 with SMTP id 40so4895415wwj.13 for ; Tue, 10 Aug 2010 21:38:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gLMzA/UFBwPrfyykTC//+c7DJiLHjElFNpIgQHPSYGs=; b=H6TpOFBXJWkIJoAH20vX87ukdjs0Q3oxi8onEGNNwIBjwQCzWS4Ut/U7hbRCPXQzSW wQuvYpfVVf7iwKC1HcHF0VloL8jNZFaXlf/yB0ZnjrehB3vw3bb6F1ikOR7GQx8K1m0a XfxK0jrGzz2WB65xZHWe6q6p31Xh1EuKcVf1c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EvdSddQFIWBmuh19HWqrTGlR/zARN98/JsKcoFKqvZIJE2hRDjDmaVvFT8oKvzYOkW K9X8AD9V5RBe+RoCdczhz1/kpYt8OW70wbj9Xp2GJE8uX3ZSTYEYPeS2VMQMaCS2qzdJ FhV28POjJBiN0mjg6VxTBBOiCs/tMQvBeQyJE= MIME-Version: 1.0 Received: by 10.227.135.75 with SMTP id m11mr15944457wbt.96.1281501501626; Tue, 10 Aug 2010 21:38:21 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 21:38:21 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> Date: Tue, 10 Aug 2010 21:38:21 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:37:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 9:33 PM, Murray S. Kucherawy wrote: >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] >> >> > Is an IANA registry a crazy idea? >> >> Perhaps, yes. >> >> Registry for what, exactly? > > As a non-North-American-centric registry for business types. > I'm still missing your point, obviously. What exactly would this accomplish, insofar as domain reputation is concerned? What prohibits bad actors from masquerading as legitimate entities? (That already happens in the domain registrar space in a big way, BTW.) I'm not following what you are suggesting, and what it would actually provide. Please explain it to me like a grade schooler. I don;t think a centralized db is, in any way, a possible solution to domain reputation services. I would also like to ask people to reconsider IODEF... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYik4q1pz9mNUZTMRAt84AJ4yvtSkB1rCZog5P1pXVQlhEBPZkgCeOujP TRQ49H1/zm3XGi06FgubVSw=3D =3Dg5hf -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster@gmail.com Tue Aug 10 21:39:55 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 029453A69E3 for ; Tue, 10 Aug 2010 21:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 t5VKbrI0iIBs for ; Tue, 10 Aug 2010 21:39:54 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id DEC453A69D7 for ; Tue, 10 Aug 2010 21:39:53 -0700 (PDT) Received: by wwj40 with SMTP id 40so4896592wwj.13 for ; Tue, 10 Aug 2010 21:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=x3VQzD9soDC5hPsKkyl6WFw25vCufhWN0i1DTaPFs4s=; b=Ihwk+gLBnzt5ed0FkW4XJI7nwU/hu1usCxINdI0WJgYB10wu85gPHtqWtNujRSjWva y2giZvHyAglCiRlP9XgK0DWIEGabL5gEYPrkfjydN5zAGg5sJ239eNlxs1lgtc9QWWZ/ pKjgkVzhtIjiQoKFrRVvdlIExDbe5dC0UKaUI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iWd3xf+iocv9N0WISAn8rg8LKquAgQ9lini9m/ueECq0Z1rlEgl6mSgBswkCUKfzfK 2S3azu5RCBc7Gws+dASECWTvciJ27LsyyfJtZSpKC2XVjNOpuGt3UUdw2vJVdWaNK03c xb6NwnWA4XN8LPFucJnETm1qz9ONcllcfgkeo= MIME-Version: 1.0 Received: by 10.227.128.18 with SMTP id i18mr16108965wbs.135.1281501629126; Tue, 10 Aug 2010 21:40:29 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 21:40:29 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 21:40:29 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:39:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 9:36 PM, Murray S. Kucherawy wrote: >> Otherwise, I fear this effort will fail just as miserably as other e- >> mail >> "reputation" systems that have come out of the IETF, with regards to >> solving a real problem. > > Are you referring to RBLs, or something else I'm not aware of? No, I'm referring to DKIM, SPF, etc. All of which have arguably failed to address the issues they were originally designed to address. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYim3q1pz9mNUZTMRAjlbAKCo3RVSDfUfwbO5sy4PuAXMGxN0kQCeNrJC WCku+IPB6TNCojsLGPuqw84=3D =3Dcqzm -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 21:44:56 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 9AF7E3A69D9 for ; Tue, 10 Aug 2010 21:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.211 X-Spam-Level: X-Spam-Status: No, score=-103.211 tagged_above=-999 required=5 tests=[AWL=-1.212, BAYES_00=-2.599, J_CHICKENPOX_31=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 HwruVg4cXIKC for ; Tue, 10 Aug 2010 21:44:56 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 039933A69D7 for ; Tue, 10 Aug 2010 21:44:56 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 21:45:31 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 21:45:30 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5Dwgefaho8JZGRo6m8w7CnTTRhwAAI0rw Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:44:56 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 9:38 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > > As a non-North-American-centric registry for business types. >=20 > I'm still missing your point, obviously. >=20 > What exactly would this accomplish, insofar as domain reputation is > concerned? It would satisfy the requirement a plurality of people have identified, nam= ely not only knowing what the reputation of a domain is and confidence in t= hat domain, but what category of business it represents. > What prohibits bad actors from masquerading as legitimate entities? I don't know how those numbers would be vetted. I imagine that would be a = product of the reputation provider. > (That > already happens in the domain registrar space in a big way, BTW.) I don't think that's news to anyone. > I don;t think a centralized db is, in any way, a possible solution to > domain reputation services. OK, but I don't think that's what I was suggesting either. How would IODEF, an incident reporting mechanism, be used to query a reputa= tion service for information about a domain name? From msk@cloudmark.com Tue Aug 10 21:46:15 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 9FE623A699E for ; Tue, 10 Aug 2010 21:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.496 X-Spam-Level: X-Spam-Status: No, score=-103.496 tagged_above=-999 required=5 tests=[AWL=-0.897, 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 TW4stbEzW9Jd for ; Tue, 10 Aug 2010 21:46:14 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id DE9BC3A68B0 for ; Tue, 10 Aug 2010 21:46:14 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 Aug 2010 21:46:50 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 21:46:48 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5D1QcD9unBaWKQJ6ob/is0hAqkgAALccA Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:46:15 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 9:40 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > >> Otherwise, I fear this effort will fail just as miserably as other > e- > >> mail > >> "reputation" systems that have come out of the IETF, with regards to > >> solving a real problem. > > > > Are you referring to RBLs, or something else I'm not aware of? >=20 > No, I'm referring to DKIM, SPF, etc. Where or when did DKIM, SPF, etc. purport to be reputation systems? > All of which have arguably failed to address the issues they were > originally designed to address. Arguably, sure. But I believe the very premise of such an argument is in e= rror. From fergdawgster@gmail.com Tue Aug 10 21:51:44 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 B347F3A68B0 for ; Tue, 10 Aug 2010 21:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_31=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 VIDitV36eIPL for ; Tue, 10 Aug 2010 21:51:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 2D2CD3A68D7 for ; Tue, 10 Aug 2010 21:51:43 -0700 (PDT) Received: by wyb40 with SMTP id 40so12719810wyb.31 for ; Tue, 10 Aug 2010 21:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=g2I8Bss0CSsyTG7PGKeFLIV2Q8ENtbZ3uB9A17OiA2A=; b=UV4xqfcRbUd4BuX6560UDsQMD+X3j18KqgmwnZo11c82mtNX0MOIpP+sBrDDRj/Zhs WwObRp2ujgXncOWQVmr19hbIJ8XsLD8kQp2hcjwM4kVGEOpAaJFPvGUQ5iA2ZEw1Am2s WGocHv1WnxXdUCf7VhImJfRVLD8mjhRLCLcRE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=F2NlB5aZa44B3T/t8uYJL3jdh02ld748dISzg7BW/y9UBs4+MI/aYkx9T6LTcv4ry8 floaDOj/jmZKHPUO3g3BfcbIRu5xrxeDPehb2ILWBPC/DiteYY7PqV9KNjF13j3Ctstg OSQ0Yt+H4mBuR5nAo/07J6xApTevTChsFeUEE= MIME-Version: 1.0 Received: by 10.216.236.42 with SMTP id v42mr4784120weq.10.1281502338380; Tue, 10 Aug 2010 21:52:18 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 21:52:18 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> Date: Tue, 10 Aug 2010 21:52:18 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:51:44 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 9:45 PM, Murray S. Kucherawy wrote: > > It would satisfy the requirement a plurality of people have identified, > namely not only knowing what the reputation of a domain is and confidence > in that domain, but what category of business it represents. > I'm not so sure that is actually true, nor possible. I don;t think there is any reasonable way for any one particular entity to "categorize" or "classify" a domain as belonging to a particular category. Believe me when I tell you, it's a hellish task -- even SVM machine learning is evolving to meet this demand (I know, we have engineers working on this). >> What prohibits bad actors from masquerading as legitimate entities? > > I don't know how those numbers would be vetted. I imagine that would be > a product of the reputation provider. > Define: reputation provider. That's a loaded term if I've ever heard one. :-) > > How would IODEF, an incident reporting mechanism, be used to query a > reputation service for information about a domain name? > IODEF is an extensible, XML-based system which can be used to exchange information -- it just struck me as a very good way to exchange domain reputation data. That is, after folks agree on the (preferably scalar) ratings used to classify domain rankings. $.02, - - ferg - -- -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYix7q1pz9mNUZTMRAlX8AJ9YcDcsQA9pPMOSaW4scyUXU0BbpwCfbA02 voKBymVGH32OtsrAn8ocrJo=3D =3DCvCh -----END PGP SIGNATURE----- "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster@gmail.com Tue Aug 10 21:55: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 07D373A68B0 for ; Tue, 10 Aug 2010 21:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 kSxRt78OBJ9R for ; Tue, 10 Aug 2010 21:55:28 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id E4AC33A67B4 for ; Tue, 10 Aug 2010 21:55:27 -0700 (PDT) Received: by wyb40 with SMTP id 40so12722220wyb.31 for ; Tue, 10 Aug 2010 21:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E3AAamVRV3UkKjE/w/71Bm0rNIKa4cc1E5bpsPWYl9U=; b=H/Dk7V8YZvvdlUth2qJ0M+xShgYBaxgGm8/5RIKl0+MswDWdyQeyQZDU21J2QIqwU5 s19wEL5csDrCZce7k2DtQ1NPjPEAcgW9Yb3nY7RA0/An0AlT2mDPnUQsHNYY5YNUN7Hs IdObDtZ0QvoLINDSSPHrmGFO+GcxcQae/EKms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q98R+Thwu282iR6y1yVxLKFl7+32W7ENEu5RF4lb356DzLvpzyaCXw9XG7jniTmx7q w1v0ZDWL3BJbqGsAlh5C4UeS7Y+eqeuNZZDnEiCPcHG/t+dE07kkK4FsbL9GRTyIkKLs q/0QpTcwrzcQLN+fiznEqwusWMTeNrOnSGgIc= MIME-Version: 1.0 Received: by 10.227.138.134 with SMTP id a6mr16098065wbu.68.1281502563119; Tue, 10 Aug 2010 21:56:03 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 21:56:03 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 21:56:03 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 04:55:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 9:46 PM, Murray S. Kucherawy wrote: >> > >> > Are you referring to RBLs, or something else I'm not aware of? >> >> No, I'm referring to DKIM, SPF, etc. > > Where or when did DKIM, SPF, etc. purport to be reputation systems? > >> All of which have arguably failed to address the issues they were >> originally designed to address. > > Arguably, sure. But I believe the very premise of such an argument is in > error. > I don't think it is in error at all. The very first instances of discussion on this mailing list were from folks in the e-mail reputation "discipline". Please connect the dots on your own. Let's please not make that mistake again in this effort. We have a real possibility this time to define & create something useful, but if it gets hijack by anti-spam interests alone, I feel this will simply divulge into another useless IETF exercise of vendors protecting their own business models. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYi1eq1pz9mNUZTMRAmlKAKDZF4E6Xc1MeGrgIk1zPyV/SaMBdQCfQc34 Yj9gG4cdXtIOZMctMso8iMo=3D =3DKRhC -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 22:04:52 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 086F23A69F2 for ; Tue, 10 Aug 2010 22:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.198 X-Spam-Level: X-Spam-Status: No, score=-103.198 tagged_above=-999 required=5 tests=[AWL=-1.199, BAYES_00=-2.599, J_CHICKENPOX_31=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 r9mN8J3LBuJ3 for ; Tue, 10 Aug 2010 22:04:51 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 201263A699E for ; Tue, 10 Aug 2010 22:04:51 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 Aug 2010 22:05:26 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 22:05:26 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5EPsJT7704ViTQzGN8/gbQjncRgAAIQTg Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:04:52 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 9:52 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > I'm not so sure that is actually true, nor possible. I don;t think > there is > any reasonable way for any one particular entity to "categorize" or > "classify" a domain as belonging to a particular category. The US Census Bureau apparently disagrees. This is precisely what NAICS is= for. > Define: reputation provider. An agent that provides reputation services, namely the expression of estima= tion of standing of an entity based on its past observed behavior. Within = context, it's a service that provides a conversion between a domain name an= d a scalar (or some other data set) that expresses such an estimation, perh= aps coupled with an expression of confidence in that estimation. > That's a loaded term if I've ever heard one. :-) Seems fairly straightforward to me. From johnl@iecc.com Tue Aug 10 22:04:57 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 91C233A69F8 for ; Tue, 10 Aug 2010 22:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.31 X-Spam-Level: X-Spam-Status: No, score=-108.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_50=0.001, 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 Ie8OMeqzWEk2 for ; Tue, 10 Aug 2010 22:04:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 2281A3A69F7 for ; Tue, 10 Aug 2010 22:04:56 -0700 (PDT) Received: (qmail 97569 invoked from network); 11 Aug 2010 05:05:31 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Aug 2010 05:05:31 -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=k1008; olt=johnl@user.iecc.com; bh=jI8ZOq1/5flz/K4R9aDHRxG3i3m3nCMUBePtafjZUbo=; b=vWFRyNLlwwYqkWvjvQu/R5/49O1ICo8JaHwWcY3boR5q/8hh3OmHg+1ddj4xfPyW+oVJQ6zy0+NYBirUO96v75JLNsJsk3JnjnENfiMc/xu4dObFJ9YrKNL8BmgKaCFTZcTMYzoCsJUEedJragGVCEZ9SHgJtYxWekHcH77B5X8= Date: 11 Aug 2010 05:05:30 -0000 Message-ID: <20100811050530.57875.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] A sketch of a small query reputation system 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, 11 Aug 2010 05:04:57 -0000 >> It's true, NAICS is managed by the US census bureau, but so what? >> I'm not aware of any other coding scheme that's as widely used. If >> there is one, I'm happy to use that instead. >Is an IANA registry a crazy idea? Well, yes. NAICS is a list of about 1100 business types managed by the US Census Bureau. It really is North American, not just US like its predecessor SIC, with input from the Canadian and Mexican statistical agencies who also use it. It's the result of a lot of effort by people who know vastly more about categorizing organizations than any of us do. For anyone who cares about this, here's the NAICS web site, where you can look at all the categories: http://www.census.gov/eos/www/naics/ The UN has something called ISIC, but it seems to be much less widely used, and looks awfully clunky. Class 6190 includes dialup ISPs, satellite base stations, and telecom resellers. But central banks have their own class 6411. http://unstats.un.org/unsd/cr/registry/isic-4.asp R's, John From johnl@iecc.com Tue Aug 10 22:09:37 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 AB57F3A69F0 for ; Tue, 10 Aug 2010 22:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.317 X-Spam-Level: X-Spam-Status: No, score=-109.317 tagged_above=-999 required=5 tests=[AWL=1.282, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_31=0.6, 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 eGabF22-kr5s for ; Tue, 10 Aug 2010 22:09:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 8D6273A69D9 for ; Tue, 10 Aug 2010 22:09:36 -0700 (PDT) Received: (qmail 99307 invoked from network); 11 Aug 2010 05:10:12 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Aug 2010 05:10:12 -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=k1008; olt=johnl@user.iecc.com; bh=Tw+3ZJzB98uH54Mu/OKueeGrreofeFfHvBfIuOMh4eU=; b=1wgoBBdw/x4p5WgH2I0rHkU6YeP5dsIioqETzZOUZ4qidLj3x74juhSNAbBUot3MHBVR+5E+RgT3up6v33odT6i4+zSiPDW6wRC5HE9/ERguXT+QqSgmI2KRw9LvuCYn8XAV5MmgxLAfEpLVWWzDvF1qN/KKzMyLMDHHTUyoWA0= Date: 11 Aug 2010 05:10:12 -0000 Message-ID: <20100811051012.59022.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] A sketch of a small query reputation system 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, 11 Aug 2010 05:09:37 -0000 > I'm not so sure that is actually true, nor possible. I don;t think > there is any reasonable way for any one particular entity to > "categorize" or "classify" a domain as belonging to a particular > category. So, just to be sure I understand you properly, you're asserting that it's impossible to say that bankofamerica.com is a bank? (That's NAICS category 522110.) In case it's not obvious, nobody expects to use AI to assign business type codes automatically. I expect to use a combination of manual inspection and grep. R's, John From msk@cloudmark.com Tue Aug 10 22:11: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 0B7ED3A69FA for ; Tue, 10 Aug 2010 22:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.484 X-Spam-Level: X-Spam-Status: No, score=-103.484 tagged_above=-999 required=5 tests=[AWL=-0.885, 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 9mxQNDmnuM-b for ; Tue, 10 Aug 2010 22:11:36 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id E90E83A69D9 for ; Tue, 10 Aug 2010 22:11:35 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Tue, 10 Aug 2010 22:12:11 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 22:12:11 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5EYDieC1bDwjOS8Kpt/V7YKFcrQAAWKPQ Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:11:41 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 9:56 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > >> > Are you referring to RBLs, or something else I'm not aware of? > >> > >> No, I'm referring to DKIM, SPF, etc. > > > > Where or when did DKIM, SPF, etc. purport to be reputation systems? >=20 > The very first instances of discussion on this mailing list were from > folks > in the e-mail reputation "discipline". >=20 > Please connect the dots on your own. >=20 > Let's please not make that mistake again in this effort. That wasn't my question. None of the technologies you identified ever purported to be reputation ser= vices. Indeed, the people working on DKIM have long identified reputation = about a domain to be what DKIM needs to be truly useful. The difference wa= s acknowledged a very long time ago. So to assert that DKIM (or the others= ) failed to provide reputation, something it never promised, is specious at= best. We're sunk from the get-go if we can't differentiate among things like auth= entication, authorization and reputation. From fergdawgster@gmail.com Tue Aug 10 22:13: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 066383A69F0 for ; Tue, 10 Aug 2010 22:13:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, J_CHICKENPOX_31=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 kFZhKfdHRPB6 for ; Tue, 10 Aug 2010 22:13:21 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 303023A69D9 for ; Tue, 10 Aug 2010 22:13:21 -0700 (PDT) Received: by wyb40 with SMTP id 40so12733982wyb.31 for ; Tue, 10 Aug 2010 22:13:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=j9QSPrViR42zZwlpqCI/lHZceYELN4rPxtMKup4WSVI=; b=x7i+uJ72V/UHC057KdMCpytu6F987cSzjMj+tJArpyYhcWY+6Lze1rlr4ac7lAfwCM fqXusW9OO/RY49dZu8PA/K4tJ8bZ+5C/yti0y+4h7zjXzeTkKGisRR92cR37WSO7VdE8 kBMMbwpkRLqiJUp2XnckDO17s0HqpP5hO64vw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aJHlNvTGQz6xmadrylHmbuNsbiFlHAVXfZSuSuVzNJ16mMBsShX/DBuLL4zbQDZC6F JYZzTLvQN256h4gRhXWs1qyvfoYww6Ir4Zt2Ihcw0SnUJhCBRcLsqaHHfGFvMKlAGWfl 2eP4mESPwdzEHw83ykm3vd2lONqRQOzJ/7iv0= MIME-Version: 1.0 Received: by 10.216.47.80 with SMTP id s58mr5207526web.15.1281503636351; Tue, 10 Aug 2010 22:13:56 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:13:56 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> Date: Tue, 10 Aug 2010 22:13:56 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:13:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:05 PM, Murray S. Kucherawy wrote: >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] >> >> I'm not so sure that is actually true, nor possible. I don;t think >> there is >> any reasonable way for any one particular entity to "categorize" or >> "classify" a domain as belonging to a particular category. > > The US Census Bureau apparently disagrees. This is precisely what NAICS > is for. > This is obviously *not* the U.S. Census, and you should be ashamed of yourself for being so U.S. Government-centric. Really. This -- first and foremost -- is an exploratory discussion list of the IETF, which is not under the auspices of any government, nor is it particularly answerable to any government. Please do not be offended by my asking, but have you worked within the IETF in the past? >> Define: reputation provider. > > An agent that provides reputation services, namely the expression of > estimation of standing of an entity based on its past observed behavior. > Within context, it's a service that provides a conversion between a > domain name and a scalar (or some other data set) that expresses such an > estimation, perhaps coupled with an expression of confidence in that > estimation. > There *cannot* be a single "reputation provider". That is why that term is loaded. It *must* be a multi-directional information exchange, and that is why I suggested IODEF as the info exchange mechanism, It just works. >> That's a loaded term if I've ever heard one. :-) > > Seems fairly straightforward to me. > > No. Definitely not. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjGPq1pz9mNUZTMRAo4jAKD6onGIkxZJETSZEWp+uInCt67KewCeP4H8 kV1Mz+RnFKDNAj1FWbUqxIc=3D =3DlGZS -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster@gmail.com Tue Aug 10 22:17: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 69BD53A69F7 for ; Tue, 10 Aug 2010 22:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_31=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 aDfF-wDcm6ZB for ; Tue, 10 Aug 2010 22:17:38 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 848103A699E for ; Tue, 10 Aug 2010 22:17:35 -0700 (PDT) Received: by wwf26 with SMTP id 26so4604962wwf.1 for ; Tue, 10 Aug 2010 22:18:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=q/3EsTEFQJeJQI8mSSeMeybdEO7CoNUO9shqq1OK5qU=; b=W3Q8InJ1KFwuhSZZ69A+3UbbY8832ga9B95YfGi3upSGq9rhx/3uYzbPPiciK5Yt/s yYg/OyG9KgvPXcDl4wR3LerS4ev2QXjOa342BGYKJhtkBycaqLFBX7Q2/zeAh6lhyCI7 XCeJPkxAPqB43B1xLFMwGtJNNtZLLFCmjAtWI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wbGgHB25BdNWxKsAWdpStmifuBGYM+9hBBkpBQ1uHcB2yXkxaaC/ib+AqKw/yeM6ko DflkIkRVpe2xMNHIFq1uzq0+QaEyzMMunumGOSMlPZwEEqfij5Y/Xj1Y4BQixqgNnOnr Ly50a0C9S0Mco25vqDudIFLEmOwKTPDayRJJo= MIME-Version: 1.0 Received: by 10.216.178.200 with SMTP id f50mr11201852wem.62.1281503890411; Tue, 10 Aug 2010 22:18:10 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:18:10 -0700 (PDT) In-Reply-To: <20100811051012.59022.qmail@joyce.lan> References: <20100811051012.59022.qmail@joyce.lan> Date: Tue, 10 Aug 2010 22:18:10 -0700 Message-ID: From: Paul Ferguson To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:17:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:10 PM, John Levine wrote: >> I'm not so sure that is actually true, nor possible. I don;t think >> there is any reasonable way for any one particular entity to >> "categorize" or "classify" a domain as belonging to a particular >> category. > > So, just to be sure I understand you properly, you're asserting that > it's impossible to say that bankofamerica.com is a bank? (That's > NAICS category 522110.) > > In case it's not obvious, nobody expects to use AI to assign business > type codes automatically. I expect to use a combination of manual > inspection and grep. > Hi John, No it is easy to say bankofamerica.com is actuallt Bank of America is it meets certain criteria (e.g. IP address, CERTs, etc.). That's easy stuff. :-) Can you tell me that bannkoamericainc.com.ru is real? These are the issue I'm driving towards, if you follow me... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjKOq1pz9mNUZTMRAmxrAKDD3NB6FXhDk5SQaY7Do7GH9bHWLgCdGPE7 G5ZAKOKs5PGMuspFGbxo3Ko=3D =3Dx+FW -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 22:19: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 5FDA93A69FC for ; Tue, 10 Aug 2010 22:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.474 X-Spam-Level: X-Spam-Status: No, score=-103.474 tagged_above=-999 required=5 tests=[AWL=-0.875, 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 rMVlNKTwKRLq for ; Tue, 10 Aug 2010 22:19:14 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id F01323A69F0 for ; Tue, 10 Aug 2010 22:19:13 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 22:19:49 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 22:19:48 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5FACJ757t0vizT7uYe1NdwUaPKgAABg1w Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:19:16 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 10:14 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > This is obviously *not* the U.S. Census, and you should be ashamed of > yourself for being so U.S. Government-centric. Really. It's not even available as an example of a mechanism for classifying compan= ies? You play by interesting rules. Let's keep the theatrics to a minimum, please. > This -- first and foremost -- is an exploratory discussion list of the > IETF, which is not under the auspices of any government, nor is it > particularly answerable to any government. Nor was any such claim made. > Please do not be offended by my asking, but have you worked within the > IETF > in the past? I appear to know enough IETF procedure to get this list created. You do th= e math. > There *cannot* be a single "reputation provider". That is why that term > is > loaded. I also didn't say there can be only one. I expect a market of them to exis= t, just as is the case today. I would like to see that grow. > It *must* be a multi-directional information exchange, and that is why > I > suggested IODEF as the info exchange mechanism, It just works. That goes to how reputation is computed, and I submit that that particular = issue should be out of scope, at least for now. From fergdawgster@gmail.com Tue Aug 10 22:21: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 D8E363A69FB for ; Tue, 10 Aug 2010 22:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 4mT7eHvEOxsl for ; Tue, 10 Aug 2010 22:21:31 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 8EB973A69FA for ; Tue, 10 Aug 2010 22:21:31 -0700 (PDT) Received: by wwj40 with SMTP id 40so4920368wwj.13 for ; Tue, 10 Aug 2010 22:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=G9NS9t8o+tSOB2BWuYNUUHfDhYpyjMmQazb+nYewye0=; b=mXqtKNvVYedG0UMLBJsG+Da+D9mDueUFb5Bma+RkoP9B6IuKSYrvfXfaU+Cn1xfY45 /y0fZWFRbLA041XUM5fL++S9IXUkyWugQevnkG1mHRlmL2cWyLa0Jm4YJJXWT7SmxWWO m1qxj3RDHuDJN5ZSb/vz+LQ+u9IhR3qRAXm8s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AuWCKumcon5kxPuKSSbU8yA6zMmBEyFxgg8mkiZsAgOX6wkN5DHr1U94vK+2wxs6Ou DY7DiFu4HS9I84E61AuIMnwxCpMfnrAlmL8kqBMrMHD+w1/F/3f7MmiG81S0Dutg6ztL zYevb7SqaH/yqQRc5TSj6RcIIbe4tGyq78USc= MIME-Version: 1.0 Received: by 10.216.54.132 with SMTP id i4mr4771026wec.50.1281504123967; Tue, 10 Aug 2010 22:22:03 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:22:03 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 22:22:03 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:21:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:12 PM, Murray S. Kucherawy wrote: >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] >> >> Let's please not make that mistake again in this effort. > > That wasn't my question. > > None of the technologies you identified ever purported to be reputation > services. Indeed, the people working on DKIM have long identified > reputation about a domain to be what DKIM needs to be truly useful. The > difference was acknowledged a very long time ago. So to assert that DKIM > (or the others) failed to provide reputation, something it never > promised, is specious at best. > Exactly. DKIM is arguably a miserable failure, only that you trust a signature for an entire domain which actually cannot be trusted. I see it every day. I see domains with DKIM signatures sending spam, malware, and other trash. So please explain to me what DKIM solves. > We're sunk from the get-go if we can't differentiate among things like > authentication, authorization and reputation. > That is exactly right, too. Which is exactly why we are having this conversation. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjN3q1pz9mNUZTMRAg80AKD9G9JQGQv4tzE+iZAEQgL72nptCgCgjDVE foQH+6ylhKFsxCLIbe/RfOU=3D =3Dz/HE -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From johnl@iecc.com Tue Aug 10 22:23:51 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 A9F513A69EF for ; Tue, 10 Aug 2010 22:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.644 X-Spam-Level: X-Spam-Status: No, score=-109.644 tagged_above=-999 required=5 tests=[AWL=1.555, 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 nnIZTX3fLWUW for ; Tue, 10 Aug 2010 22:23:50 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id E5E523A69FA for ; Tue, 10 Aug 2010 22:23:48 -0700 (PDT) Received: (qmail 5505 invoked from network); 11 Aug 2010 05:24:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=rDQKOS/uhRQBzKQY4v3SZFxTsGCEiNcvt24Tja1uGUQ=; b=K8oM/6IkqESz5czkSj3qBWiOob4cZlPBNgaRlPV9DEg2XjsyKAPvOoEht7R7H+VqCkR+fp5+eqeKG1pLHvAtPEX64TLy3/aYbu1vv21GwYS2zjqYG5JzZXwAMCLdOeAvwx1bNbEF2ZkJkBIwK9h1TVCrHf5CEWrA6JeaNfMXM1M= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 05:24:01 -0000 Date: 11 Aug 2010 01:24:23 -0400 Message-ID: From: "John R. Levine" To: "Paul Ferguson" In-Reply-To: References: <20100811051012.59022.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:23:52 -0000 > No it is easy to say bankofamerica.com is actuallt Bank of America is it > meets certain criteria (e.g. IP address, CERTs, etc.). > > That's easy stuff. :-) > > Can you tell me that bannkoamericainc.com.ru is real? I have no idea, so were I to publish a reputation opinion about that domain, I'd make the NAICS code zero. Do you really think that it's necessary to have accurate knowledge about every domain on the planet to have a useful reputation system? Don't be silly. R's, John From fergdawgster@gmail.com Tue Aug 10 22:26:15 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 495D63A6830 for ; Tue, 10 Aug 2010 22:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 bNsddPVKVlF2 for ; Tue, 10 Aug 2010 22:26:12 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 32EB73A681B for ; Tue, 10 Aug 2010 22:26:12 -0700 (PDT) Received: by wyb40 with SMTP id 40so12742194wyb.31 for ; Tue, 10 Aug 2010 22:26:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tSYr69XeHO4Uo8S7KdFquT55VP/y8YXgAlevKY8Utn0=; b=JnowEhGaGUDicenPu+fhZbD27DXSlQqcNP0ZEHfv0DTuWxbCH1dN3IOd9n/6tBiQJl 1TIoIsoaCGbz1e30G0D9l4ZCWUx35xTdUNboh9y6s1k5N+FMcxCn+4ICudseDspzT2Gd rd9kJk54EGvngWU7l5vnUoDHzWqHZoBtqQlOg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bdJ1KaMappEmqYRLN2aK+2BO6KnwKScPYrKOB2RdfrXkkMjZGGWmroAtG5dnkfLFtw XoYOhfNDbOa9tu3DZWqGVBlOl2+ujt1lS10dvH8b2e3doYRxHMYm0juINCY4kmEN1TYU VvbiEG0KaQufQUinSTRm+zN5pP9ip0l/whAWE= MIME-Version: 1.0 Received: by 10.216.235.106 with SMTP id t84mr10582182weq.46.1281504407428; Tue, 10 Aug 2010 22:26:47 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:26:47 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> Date: Tue, 10 Aug 2010 22:26:47 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:26:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:19 PM, Murray S. Kucherawy wrote: >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] >> >> This is obviously *not* the U.S. Census, and you should be ashamed of >> yourself for being so U.S. Government-centric. Really. > > It's not even available as an example of a mechanism for classifying > companies? You play by interesting rules. > What? The U.S. Government is suddenly the authority on what is a legitimate business? Please. No *government* should be involved in domain reputation issues *ever* -- never. > Let's keep the theatrics to a minimum, please. > Indeed. > >> Please do not be offended by my asking, but have you worked within the >> IETF >> in the past? > > I appear to know enough IETF procedure to get this list created. You do > the math. > Please accept my apologies on that -- I've been involved with the IETF for almost 20 years, and I get a bit upset when I think technologies are being "misdirected". - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjSPq1pz9mNUZTMRAouLAKD2RRS2xM6xn3BHBJVVNgYXeHdJvwCg7mAD +3NlRP9SxCqRubZgbft12FM=3D =3D4un/ -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster@gmail.com Tue Aug 10 22:28: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 E8E113A6830 for ; Tue, 10 Aug 2010 22:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 HHT7+3qV8Pff for ; Tue, 10 Aug 2010 22:28:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5528C3A681B for ; Tue, 10 Aug 2010 22:28:23 -0700 (PDT) Received: by wyb40 with SMTP id 40so12743501wyb.31 for ; Tue, 10 Aug 2010 22:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=LPva4FWCIG7K4TcFkBH/m1h5GAbHObT3Gyr1Sj4KlHQ=; b=lRqXLs1OgxPmJf2db6wAkQaSzIpT80wcirpoAlSHkhU+jLnPOlvUSvivAtRtz3C4Yn ST4PEK8iioHk/kV5z5ppuRSTNat5IVpR330rTvVQrbaGc3L44xOCt1uO3yGnLmj2sp+6 a5nefesmywDthBwirGE75Kvh7AAYlFm/0l+BY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ilZsER/XFwj8U30SbDsmzVnh924AHd6Ika2pj6qn3Cje9QUu8RxxI7FAqZ6M4oA6Ol 5S7upDyMLneAQA+00zjq2qRNG0Z/Ji8XgyVdcd4Jm9XxzbmYYivHeIHbWQrfTr6632He +7JWHNeS4lbnLQdXBjuX1RQCzOgmuJGxvU/g8= MIME-Version: 1.0 Received: by 10.216.74.75 with SMTP id w53mr13133826wed.86.1281504538531; Tue, 10 Aug 2010 22:28:58 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:28:58 -0700 (PDT) In-Reply-To: References: <20100811051012.59022.qmail@joyce.lan> Date: Tue, 10 Aug 2010 22:28:58 -0700 Message-ID: From: Paul Ferguson To: "John R. Levine" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:28:27 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:24 PM, John R. Levine wrote: >> No it is easy to say bankofamerica.com is actuallt Bank of America is it >> meets certain criteria (e.g. IP address, CERTs, etc.). >> >> That's easy stuff. :-) >> >> Can you tell me that bannkoamericainc.com.ru is real? > > I have no idea, so were I to publish a reputation opinion about that > domain, I'd make the NAICS code zero. > > Do you really think that it's necessary to have accurate knowledge about > every domain on the planet to have a useful reputation system? Don't be > silly. > Of course not -- don't be silly. :-) However, there can always be a category of "unknown". There can always be a category of "known malicious". Etc. Think beyond knowing everything. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjUWq1pz9mNUZTMRAhiOAJ9Flx1nMsox3QI20+uALvxGCoy/QQCdGac+ ReY7FmoEW2Nv0yN1USTzs44=3D =3D6VWH -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From johnl@iecc.com Tue Aug 10 22:32:26 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 61CB43A69EF for ; Tue, 10 Aug 2010 22:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.686 X-Spam-Level: X-Spam-Status: No, score=-109.686 tagged_above=-999 required=5 tests=[AWL=1.513, 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 ffRjZ44Hxdir for ; Tue, 10 Aug 2010 22:32:24 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id E84C03A681B for ; Tue, 10 Aug 2010 22:32:23 -0700 (PDT) Received: (qmail 8890 invoked from network); 11 Aug 2010 05:32:59 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 11 Aug 2010 05:32:59 -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=k1008; olt=johnl@user.iecc.com; bh=Eg4H0Vs3UDZp25e2bIcWagq+44Ivcr1EV5CA/KSoI0M=; b=bV/yz2uSLoQ1V9qzO22BxNcLPh8uBfCtgXmXKJKNxr9i6InSeNxm6XIK3jec+34lUELrWaMYDGFEIMfspaV4ZNGlEk5kaWuJp5o5Ojz0oYwSn5MU/+49OZXceAVMsx7EYJn8lh/jg4bZ59P4pMvbtu6jg2ZyjEe7eU6ty7gyX4k= Date: 11 Aug 2010 05:32:59 -0000 Message-ID: <20100811053259.64546.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] A sketch of a small query reputation system 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, 11 Aug 2010 05:32:26 -0000 >I see domains with DKIM signatures sending spam, malware, and other >trash. So please explain to me what DKIM solves. Wow, this is like replaying greatest hits of five years of the DKIM mailing list. I think your question is answered reasonably well by the abstract to RFC 4871. R's, John From msk@cloudmark.com Tue Aug 10 22:34: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 2D6703A68C0 for ; Tue, 10 Aug 2010 22:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.464 X-Spam-Level: X-Spam-Status: No, score=-103.464 tagged_above=-999 required=5 tests=[AWL=-0.865, 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 kO0de2J+owhk for ; Tue, 10 Aug 2010 22:34:30 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 0138A3A6830 for ; Tue, 10 Aug 2010 22:34:30 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 22:35:05 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 10 Aug 2010 22:35:05 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5FSMzwW1syTJDQhOsdcB1Se2p2wAAGegQ Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> 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] A sketch of a small query reputation system 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, 11 Aug 2010 05:34:31 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 10:22 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > DKIM is arguably a miserable failure, only that you trust a signature > for > an entire domain which actually cannot be trusted. I see it every day. >=20 > I see domains with DKIM signatures sending spam, malware, and other > trash. > So please explain to me what DKIM solves. I suspect you, like so many others, appear to have put more faith in DKIM t= o be a silver bullet for solving spam or phishing than it deserved. I thin= k that's unfortunate, possibly a problem of hype and possibly a problem of = bad early marketing on the part of its proponents, in either case establish= ing incorrect expectations. But not one of these technologies ever claimed to be reputation systems, wh= ich is what you asserted. DKIM does precisely what it claims to do. The abstract of RFC4871 states i= t nicely. I don't have any idea where you got reputation from that. That = it is a "miserable failure" because it didn't live up to that hype is certa= inly dramatic, but false. DKIM and SPF mix authentication and authorization. They connect to reputat= ion systems nicely, but they are not themselves reputation mechanisms. From fergdawgster@gmail.com Tue Aug 10 22:37:33 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 7A81E3A68C0 for ; Tue, 10 Aug 2010 22:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_31=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 utuIWy3y2LV8 for ; Tue, 10 Aug 2010 22:37:32 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 4CD653A67A7 for ; Tue, 10 Aug 2010 22:37:32 -0700 (PDT) Received: by wwj40 with SMTP id 40so4929414wwj.13 for ; Tue, 10 Aug 2010 22:38:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IAI/PvKcC2SL6poTSs3BgNQ+XxSsV/IhqfgyHtk7VO8=; b=AhBppYQgg7GUaJTODmWgpOw8kMB1v6xsZoSyuPMNaxkGWLFE4RdDW/E1/mO22e6eLs dJn6wmygKFL3iQWM1KpBZuBDxpIthwla9Gwo6iR2mWi6IR7YLVBrvCfMwf6/+/Vc5Fbi 1gKOwOXEz0Mgi8OJ6JVI6MlfFQ8AobxM+8J8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rJ+nHJlZG3gXSAzdoNyJArJyuQ0rwCLY30juK71Ra/cUgSxE1eLwHgwnQ/4xJhINLT j3qDnglDA/WX8g32zwTj+dsv8Sgsnsr02/POTJIZGkGG8F87/P46twupZv0xiSsXLCli NEqdCuEDdkskzRf7TvuRiEYSAoXI1PWSx2e00= MIME-Version: 1.0 Received: by 10.227.38.82 with SMTP id a18mr15816088wbe.181.1281505086459; Tue, 10 Aug 2010 22:38:06 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:38:06 -0700 (PDT) In-Reply-To: <20100811053259.64546.qmail@joyce.lan> References: <20100811053259.64546.qmail@joyce.lan> Date: Tue, 10 Aug 2010 22:38:06 -0700 Message-ID: From: Paul Ferguson To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:37:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:32 PM, John Levine wrote: >>I see domains with DKIM signatures sending spam, malware, and other >>trash. So please explain to me what DKIM solves. > > Wow, this is like replaying greatest hits of five years of the DKIM > mailing list. > > I think your question is answered reasonably well by the abstract > to RFC 4871. > John, This is exactly why I don;t want to see an effort to define domain reputation follow along the same line of thinking, since it is so much more than that. For real. There is a real danger here of directing yourself (not necessarily *you*, but an e-mail directed effort) into insignificance. This has been the perceived relevance of various IETF efforts in the past few years (which is why I haven't been to one since Prague). $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjc5q1pz9mNUZTMRAgvIAJwPk8V4jANh7ISJx2tHAMKPnhLnZQCgyZte xlWHi0taADbwRB/ctfvKtUc=3D =3DPki3 -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From fergdawgster@gmail.com Tue Aug 10 22:40: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 B8B3D3A69EF for ; Tue, 10 Aug 2010 22:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 ypnRwI6fhMkU for ; Tue, 10 Aug 2010 22:40:02 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C2FD43A68C0 for ; Tue, 10 Aug 2010 22:40:01 -0700 (PDT) Received: by wwj40 with SMTP id 40so4930885wwj.13 for ; Tue, 10 Aug 2010 22:40:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=glhu/4juyy3zROolYMF/QZNoXH0o7m6rLTSOu6YWhJc=; b=UZpnK41FYc9bha8bYwpvYPt9h/CWFVvA7mbgECG4qFQ3vFuj+dQJk2BvAMPDurxcw8 nLcd+7kngVogDwzfcQA5L7mKsOKupiJ8GgHUjbZ/hV2QEQigLb5YEeAFwXtBaVtx9tQF G2FgRjKnofmZ1BfwX8bV51mD7pH6M1SyO8QKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kYjKDxQgVpbhQwTr0EZQdHHsZfzkMYxL0fYhd9uja+y5FztFdJfCIaq7LX8RyrrYVd sY5W+kUODRDuQHqYLnv9uQ8UOcJTzXd0K+FibklbPG9ZTt0v6R1wAMZP7XIt7QNHizUh ias2DEQ81sUrZpWD9EjAgI/a32qJA2ddoQZAE= MIME-Version: 1.0 Received: by 10.227.38.82 with SMTP id a18mr15817925wbe.181.1281505236870; Tue, 10 Aug 2010 22:40:36 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:40:36 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 22:40:36 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:40:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:35 PM, Murray S. Kucherawy wrote: >> >> DKIM is arguably a miserable failure, only that you trust a signature >> for >> an entire domain which actually cannot be trusted. I see it every day. >> >> I see domains with DKIM signatures sending spam, malware, and other >> trash. >> So please explain to me what DKIM solves. > > I suspect you, like so many others, appear to have put more faith in DKIM > to be a silver bullet for solving spam or phishing than it deserved. I > think that's unfortunate, possibly a problem of hype and possibly a > problem of bad early marketing on the part of its proponents, in either > case establishing incorrect expectations. > Actually, I don't care two bits about any either DKIM or SPF -- I'm not an anti-spam person. I'm a network security person. Spam is manageable. Malicious domains are only manageable when you start thinking about them as they actually are -- crime. Stop thinking about spam. Please. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjfOq1pz9mNUZTMRAuRHAJ48jvhbmA1oY1coLQZzbanN64e63wCePn98 aEbMpXzus5BSZY12vh5/rq0=3D =3DrJZ1 -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From msk@cloudmark.com Tue Aug 10 22:49: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 8DB9D3A69EF for ; Tue, 10 Aug 2010 22:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.454 X-Spam-Level: X-Spam-Status: No, score=-103.454 tagged_above=-999 required=5 tests=[AWL=-0.855, 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 j2BldA+bnbsj for ; Tue, 10 Aug 2010 22:49:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id C90493A68C0 for ; Tue, 10 Aug 2010 22:49:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 10 Aug 2010 22:50:07 -0700 From: "Murray S. Kucherawy" To: Paul Ferguson Date: Tue, 10 Aug 2010 22:50:05 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5F7sW/eo5mZ9cTUSIgf9XevvOxwAASX1g Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> 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 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:49:32 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Tuesday, August 10, 2010 10:41 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > Actually, I don't care two bits about any either DKIM or SPF -- I'm not > an > anti-spam person. >=20 > I'm a network security person. >=20 > Spam is manageable. >=20 > Malicious domains are only manageable when you start thinking about > them as > they actually are -- crime. >=20 > Stop thinking about spam. Please. I didn't see anyone trying to constrain any of this activity specifically t= o email or anti-spam. Can we all play nice now? From fergdawgster@gmail.com Tue Aug 10 22:53:40 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 C47793A69EF for ; Tue, 10 Aug 2010 22:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 LKS006yMSVpw for ; Tue, 10 Aug 2010 22:53:40 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id DD48C28B23E for ; Tue, 10 Aug 2010 22:53:38 -0700 (PDT) Received: by wwf26 with SMTP id 26so4628521wwf.1 for ; Tue, 10 Aug 2010 22:54:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=U/U6/CbX/QWIeBgiQJIKcD+jWy3n+oPuN8ybrXnPJqU=; b=Qt1Vh1sh+pm2Gni/MqweDsalenKjspmh4fedhau4oSnmgA5ClhlIAdZQeqYsC71nhu GByDSW5hOOhNyj0AFDicqTPkWnyk/2L/7p5+ROANOsMGGr8lHgyCOMdfKhBHbOdq1i++ FDmbwYJxZuhVSCQ8IzwaoBd1o71bfiodfDNc0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ci3ejHfv9i9cZk2HUTbC+/WC8e/vnaT4e0e07EOPh5CCYrQqHyZe3cZUMDUtX1vRs9 CfmuufC5/0EURDtOXK+kNPJnNt4FVVm5Yr40E1nOCWnjeNm4tueTeEjgwS97994Oi0ar 0X7yooyNupP95K2vfW59p4wX4yUNxYifQXxgs= MIME-Version: 1.0 Received: by 10.216.23.4 with SMTP id u4mr16046261weu.96.1281506054073; Tue, 10 Aug 2010 22:54:14 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Tue, 10 Aug 2010 22:54:13 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> Date: Tue, 10 Aug 2010 22:54:13 -0700 Message-ID: From: Paul Ferguson To: "Murray S. Kucherawy" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "domainrep@ietf.org" Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 05:53:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Aug 10, 2010 at 10:50 PM, Murray S. Kucherawy wrote: >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] >> >> Actually, I don't care two bits about any either DKIM or SPF -- I'm not >> an >> anti-spam person. >> >> I'm a network security person. >> >> Spam is manageable. >> >> Malicious domains are only manageable when you start thinking about >> them as >> they actually are -- crime. >> >> Stop thinking about spam. Please. > > I didn't see anyone trying to constrain any of this activity specifically > to email or anti-spam. > > Can we all play nice now? > Certainly! :-) Having said that, I reiterate the need to look beyond e-mail -specific technologies (e.g. DKIM, etc.) to play a role in domain reputation. It's just a bad fit. Let's open the playground to other possibilities -- e-mail has it's own unique set of problems which are not share with, say, HTTP (et al.) communicated streams. Let's please keep that in mind. Cheers, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYjr+q1pz9mNUZTMRAn9OAKC6e0YvJv9tNQnyW6dPubKWY3nHpACgu5k/ WemTFa5ajMKr38jOxYzKbSw=3D =3D+sIR -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From sm@resistor.net Wed Aug 11 01:06:13 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 71B223A6A47 for ; Wed, 11 Aug 2010 01:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.665 X-Spam-Level: X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 fqfp8-7CsseQ for ; Wed, 11 Aug 2010 01:06:11 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 41C033A6804 for ; Wed, 11 Aug 2010 01:06:06 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o7B86Q67017733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 01:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1281513996; x=1281600396; bh=ZwMN2NnemsAZnI76o2RyHS2IdN0Yr4GKdNqqePrOlXA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Fe8vMp1TJZESHULi+JPBEUQ6gtyj/tw7Qu517r/bpTdSiE+ywB0Kk3/IPvMIR/aG2 SqzDpUGuSp6wphwXgTC7D7C1PwFDhOTRQy2+pKJT4pe8ZNn95cJRmIn2gykkuvtCcn nOuo+MeNTsbBpueh6mA8qnJdcP2SfKXN+bQKDFnI= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1281513996; x=1281600396; bh=ZwMN2NnemsAZnI76o2RyHS2IdN0Yr4GKdNqqePrOlXA=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=gQfEjKiIJW0Vjpyoovnx4c3VVJG/PMqt2hxCVt079t5/WF0J87ovJvXz9dWMCEBs8 qyh2QxsM61QsiTSS+/Zx6nYN1e06M1y3nMPuaihaKY/OFkJu9hTvvJkkmee2FePInI n8o+PSGyBmJk/NwWn8+RWj4Gj7vUDOA65ETpN5WE= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=x491pXzALGcZejPd91VMcOn1tUgr7WeBO4prgn17AGyJ7pnCb8rajzZPnZhHeBcTW 1XVaqt1kWhytsfT7iuDcP6/7i5jScVcXB8xl5K9S5JPPnwJLc64Oi7Z2ZpjGlfDtiTt uW03BOUvwmYzArZtZuubLEpapqxO6tiFIdHjaXA= Message-Id: <6.2.5.6.2.20100811003513.0b5e6438@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 11 Aug 2010 01:02:01 -0700 To: domainrep@ietf.org From: SM In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 08:06:13 -0000 At 22:13 10-08-10, Paul Ferguson wrote: >Please do not be offended by my asking, but have you worked within the IETF >in the past? Murray has been doing some work in the MARF WG and DKIM WG, and in the Applications Area. There was a discussion about CRAP after the DKIM WG session at IETF78. I don't recall whether it stands for Common Reputation Access Protocol or Convey Reputation Access Protocol. This non-WG mailing list was created to follow up on the discussion. Regards, -sm From fergdawgster@gmail.com Wed Aug 11 01:26: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 2AC983A6A47 for ; Wed, 11 Aug 2010 01:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 a-hRnlzGGmzE for ; Wed, 11 Aug 2010 01:26:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 030BD3A6804 for ; Wed, 11 Aug 2010 01:26:02 -0700 (PDT) Received: by wyb40 with SMTP id 40so12870443wyb.31 for ; Wed, 11 Aug 2010 01:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=dZAezTOvKdvvjUXkGU1dNmOxzqt2NxKed/ZlRfGqf1U=; b=M/hsVtua8+hpNW9fF6lxS1m038mi/K6LaecYCU053pFvBCy4w5pg84+k5lTQjaPeyT p9VN0BZ+M407NgfdArBXWYQ6xhh4EeCzqh+AX7XmYR5M/iEMqep3MLG+Dvo0MlErmVxc /We+XkcMCYAh38TTESyBUTevt23NTXBYgFHFc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=o0WJ7iQBAoy89iViBxBYwXs2XSc7n7KRoW1ufeFpT4akgUIlf9t3ix2VSYV1I4zecN Ttom/K5RTpYiNS0wHgsuhGueCgHJuwRaUG5sNAHBEO7ChK+yZYu0yLDY/907a09tjbHK XBL5tTz2q4j6bTr+TnOm5OvKPkn20DVERfFWI= MIME-Version: 1.0 Received: by 10.216.23.206 with SMTP id v56mr4952607wev.67.1281515198143; Wed, 11 Aug 2010 01:26:38 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Wed, 11 Aug 2010 01:26:38 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20100811003513.0b5e6438@resistor.net> References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <6.2.5.6.2.20100811003513.0b5e6438@resistor.net> Date: Wed, 11 Aug 2010 01:26:38 -0700 Message-ID: From: Paul Ferguson To: SM Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 08:26:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Aug 11, 2010 at 1:02 AM, SM wrote: > At 22:13 10-08-10, Paul Ferguson wrote: >> >> Please do not be offended by my asking, but have you worked within the >> IETF >> in the past? > > Murray has been doing some work in the MARF WG and DKIM WG, and in the > Applications Area. > > There was a discussion about CRAP after the DKIM WG session at IETF78. I > don't recall whether it stands for Common Reputation Access Protocol or > Convey Reputation Access Protocol. This non-WG mailing list was created > to follow up on the discussion. > For the record, I worked with various WGs in the 90's when I worked for Cisco Systems, primarily in the routing area, since that was my forte. Full Disclosure: I now work for Trend Micro, Inc., a security company. Yes, we have our own reputation systems, however, we have properly (IMO) split them into various systems, each of which can be correlated to one another. For example, over the past 4 years or so, we have built our own "domain reputation" system. I won't go into the heuristics and logic that we use in our secret sauce, but we have made a conscience decision to make sure that we treat "domain reputation" separately based on whether it is e-mail, URLs, or malware. But we correlate the date between all of them (e.g. "Show me all foo that has bar"). In my mind, this is the true heart of domain reputation -- being able to distinguish between the "foo" and coming up with a (scalar) score for the "bar". Bear in mind, industry is already doing this. If we want to "standardize" in this area, we need to understand what we are talking about. And for the most part, the most pressing issue is not e-mail, it is URI reputation. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYl61q1pz9mNUZTMRAglVAKDRl36cKktVcM9nV06v4d7yCjuL+gCg4PEg GJgkz3iaE74bZ1MeqjLPwuk=3D =3DOWcy -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From graham+prvs=0839D6518E@gmurray.org.uk Wed Aug 11 01:59:00 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 2FD4C3A67D7 for ; Wed, 11 Aug 2010 01:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, 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 16gwVNyHGFwa for ; Wed, 11 Aug 2010 01:58:59 -0700 (PDT) Received: from newton.gmurray.org.uk (newton.gmurray.org.uk [IPv6:2001:8b0:57:1:250:8dff:fee7:7fcc]) by core3.amsl.com (Postfix) with ESMTP id AE5C53A67CF for ; Wed, 11 Aug 2010 01:58:58 -0700 (PDT) Received: from newton.gmurray.org.uk (localhost [127.0.0.1]) by newton.gmurray.org.uk (8.14.4/8.14.4) with ESMTP id o7B8xXUw029449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 11 Aug 2010 09:59:33 +0100 X-DKIM: OpenDKIM Filter v2.1.3 newton.gmurray.org.uk o7B8xXUw029449 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmurray.org.uk; s=in200703; t=1281517173; bh=ISeuFmuE/c7HOef+eoPRg1Z6fetdVJCO5gERU4mAgp8=; l=292; h=From:To:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=M96RKT39un9sFY8jcUpLI023zFA8CYFJcEzy6dLtMwi9M9G3b4fe3/Zn6p44D7gQS z+9uv+sn0f16XQmqUTBWRvQcjdk7Tnq0AvqykHqS5o2++56q+oXYENxvUZaIxIWkc2 VEpJuexMdTjDK8jP9rFHR2C7oHVyjtQK6Z2UC5p4= X-BATV: Sendmail BATV Filter v0.4.0 newton o7B8xXUw029449 Received: (from graham@localhost) by newton.gmurray.org.uk (8.14.4/8.14.4/Submit) id o7B8xWwa029448; Wed, 11 Aug 2010 09:59:32 +0100 X-Authentication-Warning: newton.gmurray.org.uk: graham set sender to graham@gmurray.org.uk using -f From: Graham Murray To: domainrep@ietf.org References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <6.2.5.6.2.20100811003513.0b5e6438@resistor.net> Date: Wed, 11 Aug 2010 09:59:32 +0100 In-Reply-To: (Paul Ferguson's message of "Wed, 11 Aug 2010 01:26:38 -0700") Message-ID: <87pqxp5xu3.fsf@newton.gmurray.org.uk> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (i686-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: clamav-milter 0.96.1 at newton X-Virus-Status: Clean Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 09:34:35 -0000 Paul Ferguson writes: > And for the most part, the most pressing issue is not e-mail, it is URI > reputation. Not forgetting that an email address can be referenced as a URI (mailto:John.Doe@example.com), so email reputation is a subset of URI reputation. From nsb@guppylake.com Wed Aug 11 06:40:01 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 B8BD53A6862 for ; Wed, 11 Aug 2010 06:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 4lSIJQJnPeTN for ; Wed, 11 Aug 2010 06:40:00 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id B1B9C3A687E for ; Wed, 11 Aug 2010 06:40:00 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OjBjz-0001QV-LX; Wed, 11 Aug 2010 09:53:12 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Wed, 11 Aug 2010 09:40:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> To: Paul Ferguson 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] A sketch of a small query reputation system 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, 11 Aug 2010 13:40:01 -0000 On Aug 11, 2010, at 1:22 AM, Paul Ferguson wrote: > DKIM is arguably a miserable failure, only that you trust a signature = for > an entire domain which actually cannot be trusted. I see it every day. >=20 > I see domains with DKIM signatures sending spam, malware, and other = trash. > So please explain to me what DKIM solves. At the first meeting in which we brought the DK and IIM teams together = to begin the work that became DKIM, we discussed long-term strategy very = explicitly. We pretty much all agreed that DKIM's utility would be = fairly low until it was supplemented with reputation systems, but that = it was unwise to try to design both at once. The current renewed = interest in reputation systems precisely reflects, I believe, the fact = that DKIM is finally "done" enough for many people to turn their = attention to the next step. Real progress against bad actors on the net will require several = separate, mutually reinforcing new technologies. If they are well = designed to work together, the fact that they aren't very useful in = isolation is no more relevant than the uselessness of any other stones = of an arch in the absence of a keystone. How about if we postpone the debate about whether or not DKIM is a = failure until *after* we have it linked to reputation systems, as its = designers always anticipated? -- Nathaniel= From nsb@guppylake.com Wed Aug 11 06:55:17 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 15F463A6900 for ; Wed, 11 Aug 2010 06:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 xVST-l5hjuj1 for ; Wed, 11 Aug 2010 06:55:15 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id BDD293A68BF for ; Wed, 11 Aug 2010 06:55:15 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OjByl-0003aB-Co; Wed, 11 Aug 2010 10:08:28 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Wed, 11 Aug 2010 09:55:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3E3A4263-BB1E-4737-B69A-D08F8A53FB43@guppylake.com> References: <20100809202036.80554.qmail@joyce.lan> To: Murray S. Kucherawy 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] large and small domain reputation 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, 11 Aug 2010 13:55:17 -0000 On Aug 10, 2010, at 12:46 PM, Murray S. Kucherawy wrote: >> 0 for not specifying the base of a secret recipe. There are a zillion >> types of beers. They all have in common water, malt, hops & yeast. = I'd >> think an information doc may be useful. >=20 > Sure, but I don't think that sort of R&D is the kind of work the IETF = does. +1. Moreover, this is one of the few areas where trade secrets -- often = denigrated as "security through obscurity" -- can actually be quite = useful over a limited time period. Even more important, secret recipes = are the kind of aspirational techniques that make investors open their = wallets, a motivation which will be hard to counter with a few IETF = documents. -- Nathaniel ----------------------------------- Nathaniel Borenstein Chief Scientist, Mimecast http://guppylake.com/nsb http://mimecast.com From dotis@mail-abuse.org Wed Aug 11 09:28: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 9FF913A6A2E for ; Wed, 11 Aug 2010 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.62 X-Spam-Level: X-Spam-Status: No, score=-105.62 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_05=-1.11, 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 c3tdDs-9XLEX for ; Wed, 11 Aug 2010 09:28:47 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 384933A6A33 for ; Wed, 11 Aug 2010 09:28:47 -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 8DBB4A94836 for ; Wed, 11 Aug 2010 16:29:20 +0000 (UTC) Message-ID: <4C62CFDF.5080704@mail-abuse.org> Date: Wed, 11 Aug 2010 09:29:19 -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: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 16:28:48 -0000 On 8/10/10 10:12 PM, Murray S. Kucherawy wrote: > > On Tuesday, August 10, 2010 9:56 PM Paul Ferguson wrote: > >>>> Are you referring to RBLs, or something else I'm not aware > >>>> of? > >>> > >>> No, I'm referring to DKIM, SPF, etc. > >> > >> Where or when did DKIM, SPF, etc. purport to be reputation > >> systems? > > > > The very first instances of discussion on this mailing list were > > from folks in the e-mail reputation "discipline". > > > > Please connect the dots on your own. > > > > Let's please not make that mistake again in this effort. > > That wasn't my question. > > None of the technologies you identified ever purported to be > reputation services. Indeed, the people working on DKIM have long > identified reputation about a domain to be what DKIM needs to be > truly useful. The difference was acknowledged a very long time ago. > So to assert that DKIM (or the others) failed to provide reputation, > something it never promised, is specious at best. > > We're sunk from the get-go if we can't differentiate among things > like authentication, authorization and reputation. Agreed. Once one moves past domains related to phishing and malware, that leaves a _minor_ number of domains. Once the truly malicious domains have been excluded, then web reputation must still deal with compromised web-pages, errant user accounts, etc. The information needed to carry out that task, without disrupting an entire domain, needs to focus upon path elements in addition to that of the domain. In either case, any query must use canonicalization to minimize the impact of random sub-domains on the service, and offer a way to restrict access to the service as a means to eliminate abusive clients. Existing services demonstrate such anti-fuzzing efforts. For email related query structures see: http://www.surbl.org/ For web related query structures see: http://code.google.com/apis/safebrowsing/developers_guide_v2.html Note the _significant_ difference between these two strategies when dealing with different protocols having different exposures. It is also naive to suggest this service can be directly achieved by publishing a DNS zone mapping the entire DNS into different categories. That ignores the portions of the Internet backbone that might be damaged when attempting to support such as service, and the level of support the service will require. There appears to be an answer for what should be the first question. This answer needs no additional integration efforts for web or email. There is an open standard that describes a zone used to over-ride the resolution of domains, such as those involved with malware or phishing. ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt The issue of supporting the information contained is supported through information exchange efforts supported by: http://www.cert.org/ietf/inch/docs/draft-ietf-inch-iodef-12.txt If you look through the information being collected, it should quickly become clear it is focused on crime related details, and not what some related web-page or certificate might claim. Frankly, criminal organizations can purchase the same infrastructure as those running legitimate services. Invariably, when their domain is blocked, they'll complain as loudly as a legitimate enterprise requesting removal, especially when the blocking service lacks anything to backup their assertions. Supporting assertions that led to a domain being blocked is not a trivial part of this process. I understand why Paul is not interested in dealing with John Levine's suggestion of offering NAICS enumeration of business types. Their job is hard enough categorizing the nature of the crime, without spending more of their time attempting to find a number for the type of criminal enterprise the US Census likely failed to categorize. DNS is not good at exchanging details that are needed to sustain listings. Because everyone uses a different database, the strategy has been to use xml schemes as templates for exchanging information between different databases. Let me suggest this effort be broken down into: a) malicious domain blocking In this effort, people working in Paul's area will have much to offer. Frankly, the problem has become so large, it seems this should be done first, and then determine what else might be needed. b) store-and-forward services This effort should focus on the types of query and query results needed for defending store and forward servers that are structured to defend the reputation service. c) relational services This effort should focus on the types of query and query results needed for defending web servers that are structured to defend the reputation service. -Doug From msk@cloudmark.com Wed Aug 11 09:30:14 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 6A5F43A6A2E for ; Wed, 11 Aug 2010 09:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.445 X-Spam-Level: X-Spam-Status: No, score=-103.445 tagged_above=-999 required=5 tests=[AWL=-0.846, 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 t5Lv8VO1Kq3Q for ; Wed, 11 Aug 2010 09:30:13 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 546AB3A6A6C for ; Wed, 11 Aug 2010 09:30:12 -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, 11 Aug 2010 09:30:48 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 11 Aug 2010 09:30:48 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5LuwNiqPkZbZxSYmG9VAB2QjarQAQyRIw Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <6.2.5.6.2.20100811003513.0b5e6438@resistor.net> 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] A sketch of a small query reputation system 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, 11 Aug 2010 16:30:14 -0000 > -----Original Message----- > From: Paul Ferguson [mailto:fergdawgster@gmail.com] > Sent: Wednesday, August 11, 2010 1:27 AM > To: SM > Cc: domainrep@ietf.org; Murray S. Kucherawy > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > And for the most part, the most pressing issue is not e-mail, it is URI > reputation. As I don't believe I saw anyone asserting that this work should be bound to= any particular application, you appear to be arguing very hard for somethi= ng that seems to me to already be a consensus view. Let's spend our energy moving forward rather than doing battle to hit the s= ame nail on the head repeatedly. From tony@att.com Wed Aug 11 14:43: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 732E728C0FF for ; Wed, 11 Aug 2010 14:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=0.651, 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 gl4-Yy5HLocl for ; Wed, 11 Aug 2010 14:43:05 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id 680B928C0F2 for ; Wed, 11 Aug 2010 14:43:05 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: tony@att.com X-Msg-Ref: server-4.tower-129.messagelabs.com!1281563020!38313814!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 16149 invoked from network); 11 Aug 2010 21:43:41 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Aug 2010 21:43:41 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7BLhCAv005107 for ; Wed, 11 Aug 2010 17:43:12 -0400 Received: from klpd017.kcdc.att.com (klpd017.kcdc.att.com [135.188.40.86]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o7BLhBwb005098 for ; Wed, 11 Aug 2010 17:43:11 -0400 Received: from kcdc.att.com (localhost.localdomain [127.0.0.1]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o7BLhdO5002520 for ; Wed, 11 Aug 2010 16:43:39 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by klpd017.kcdc.att.com (8.14.3/8.14.3) with ESMTP id o7BLhbTl002505 for ; Wed, 11 Aug 2010 16:43:38 -0500 Received: from [135.91.110.95] (dn135-91-110-95.dhcpn.ugn.att.com[135.91.110.95]) by maillennium.att.com (mailgw1) with ESMTP id <20100811214337gw100s4pvse> (Authid: tony); Wed, 11 Aug 2010 21:43:37 +0000 X-Originating-IP: [135.91.110.95] Message-ID: <4C631989.1030203@att.com> Date: Wed, 11 Aug 2010 17:43:37 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: John Levine References: <20100810231119.71971.qmail@joyce.lan> In-Reply-To: <20100810231119.71971.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 21:43:06 -0000 I feel comfortable with the direction this is heading. However, I'd change the type specific queries to use something like dubious.example._web._rep.scorekeeper.example dubious.example._mail._rep.scorekeeper.example for "type"-specific queries. Tony Hansen On 8/10/2010 7:11 PM, John Levine wrote: > Let's say you have a domain dubious.example, and you want to ask > scorekeeper.example what its reputation is. You do a DNS lookup of > > dubious.example._rep.scorekeeper.example > > Maybe it's a TXT record, maybe it's a new RR type. If scorekeeper.example > has an opinion about dubious.example, it returns a record with three > numbers it it. Perhaps they're space separated digit strings in a TXT > record, or three fields in a REPUTATION record. They are: > > Quality of domain: 0-99 with 99 being the best > > Confidence of opinion: 0-99 with 99 being most certain > > NAICS code: up to six digits, 0 if unknown, describing the type of > organization > > Note that NAICS is sort of like Dewey decimal, with longer numbers > being subclasses of shorter ones, so 92 is any government body, 922120 > is a police department, 52 is a financial institution, 5221 is a bank, > 522110 is a commercial bank, and 522130 is a credit union. > > If you want to publish different opinions for different kinds of > domain usage, you give them separate names, e.g. > > dubious.example._rep.mail.scorekeeper.example > > dubious.example._rep.web.scorekeeper.example > From johnl@iecc.com Wed Aug 11 16:31:10 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 DD1E13A68C5 for ; Wed, 11 Aug 2010 16:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.728 X-Spam-Level: X-Spam-Status: No, score=-109.728 tagged_above=-999 required=5 tests=[AWL=1.471, 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 l717WEEMZYmd for ; Wed, 11 Aug 2010 16:31:10 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 9B8E03A63EC for ; Wed, 11 Aug 2010 16:31:09 -0700 (PDT) Received: (qmail 62069 invoked from network); 11 Aug 2010 23:31:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=sqHSLVAjZLikeqqcWilXJ/otmO2OYHHxfQzNb/roops=; b=HmOeOMOLP5jSsobuCrxGdTnGws339lU3fsKN28qBevM9j552wbJNy79i6F/38qACPfUWZM78DZ5CmwyF0UhSgFBNmPC2sAceDEkow/CXigFMUX2Jh7DEAu2dMf/RxjGVog2wKwRf89doBHgnEYGgwEPWmnfVCsdNDu/w5Ehwlkw= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 23:31:22 -0000 Date: 11 Aug 2010 19:31:42 -0400 Message-ID: From: "John R. Levine" To: "Tony Hansen" In-Reply-To: <4C631989.1030203@att.com> References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 23:31:11 -0000 > I feel comfortable with the direction this is heading. However, I'd change > the type specific queries to use something like > > dubious.example._web._rep.scorekeeper.example > dubious.example._mail._rep.scorekeeper.example > > for "type"-specific queries. OK by me, although it'll be interesting to define the set of names. R's, John From msk@cloudmark.com Wed Aug 11 16:42:05 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 B8F2F28C0DB for ; Wed, 11 Aug 2010 16:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.424 X-Spam-Level: X-Spam-Status: No, score=-103.424 tagged_above=-999 required=5 tests=[AWL=-0.825, 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 JVAGuW8aCM+K for ; Wed, 11 Aug 2010 16:42:05 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 06BCB3A67B7 for ; Wed, 11 Aug 2010 16:42:05 -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, 11 Aug 2010 16:42:41 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 11 Aug 2010 16:42:40 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5rV6Jg8mTJUMoS0GvrdkUJeyaoQAAV4iA Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.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] A sketch of a small query reputation system 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, 11 Aug 2010 23:42:05 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of John R. Levine > Sent: Wednesday, August 11, 2010 4:32 PM > To: Tony Hansen > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > > I feel comfortable with the direction this is heading. However, I'd > change > > the type specific queries to use something like > > > > dubious.example._web._rep.scorekeeper.example > > dubious.example._mail._rep.scorekeeper.example > > > > for "type"-specific queries. >=20 > OK by me, although it'll be interesting to define the set of names. I think I agree. Why not leave it to the reputation provider to do this, m= aking it explicit (or general, by not using them) what the *ahem* domain of= the reputation is, and save us an IANA consideration? From paul.hoffman@vpnc.org Wed Aug 11 16:44:22 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 30AA03A69C5 for ; Wed, 11 Aug 2010 16:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.074 X-Spam-Level: X-Spam-Status: No, score=-100.074 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 v+RR1TVhgWt7 for ; Wed, 11 Aug 2010 16:44:21 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 6DD353A697B for ; Wed, 11 Aug 2010 16:44:21 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7BNibip057213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 16:44:38 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> Date: Wed, 11 Aug 2010 16:44:36 -0700 To: "John R. Levine" , "Tony Hansen" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 23:44:22 -0000 At 7:31 PM -0400 8/11/10, John R. Levine wrote: >>I feel comfortable with the direction this is heading. However, I'd change the type specific queries to use something like >> >> dubious.example._web._rep.scorekeeper.example >> dubious.example._mail._rep.scorekeeper.example >> >>for "type"-specific queries. > >OK by me, although it'll be interesting to define the set of names. Maybe consider all-digit "names": dubious.example._80._rep.scorekeeper.example ... --Paul Hoffman, Director --VPN Consortium From johnl@iecc.com Wed Aug 11 16:49: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 07A7E3A697B for ; Wed, 11 Aug 2010 16:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.754 X-Spam-Level: X-Spam-Status: No, score=-109.754 tagged_above=-999 required=5 tests=[AWL=1.445, 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 T-WgLPF6eCOM for ; Wed, 11 Aug 2010 16:49:05 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D0BAC3A68B8 for ; Wed, 11 Aug 2010 16:49:04 -0700 (PDT) Received: (qmail 68720 invoked from network); 11 Aug 2010 23:49:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=i9DPuvzzPdK+VUukwsKF7K9KAFi5FaJ1CjKhBqrAoZQ=; b=d96tpNxfWC3YNaZugcg4+uijiUGpnRjnHgV7/dy/eER92iBZBVRaA8h8/7FIdRdlVzDpqiYP/40t6C6Aos39yoSk7zD+zl1hzDvFy4Vd2iDzaU/E3oiHpvU4+e4VOTmPX8EZLEXciVk46iGLXq9wxWhn5mVguawcx5DD6yIbpFg= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 11 Aug 2010 23:49:18 -0000 Date: 11 Aug 2010 19:49:39 -0400 Message-ID: From: "John R. Levine" To: "Paul Hoffman" In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 11 Aug 2010 23:49:06 -0000 >>> dubious.example._web._rep.scorekeeper.example >>> dubious.example._mail._rep.scorekeeper.example >>> >>> for "type"-specific queries. >> >> OK by me, although it'll be interesting to define the set of names. > > Maybe consider all-digit "names": dubious.example._80._rep.scorekeeper.example ... My intention using subdomains was so that you could have different opinions of, say, mail from a domain vs. web sites hosted at the domain. I don't understand what numbers would do other than be opaque. R's, John From paul.hoffman@vpnc.org Wed Aug 11 17:06: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 699B23A6896 for ; Wed, 11 Aug 2010 17:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.005 X-Spam-Level: X-Spam-Status: No, score=-101.005 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 gCAeY2gOpufc for ; Wed, 11 Aug 2010 17:06:28 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 90C903A687C for ; Wed, 11 Aug 2010 17:06:28 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7C06kIB058166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 17:06:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> Date: Wed, 11 Aug 2010 17:06:44 -0700 To: "John R. Levine" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 00:06:29 -0000 At 7:49 PM -0400 8/11/10, John R. Levine wrote: >>>> dubious.example._web._rep.scorekeeper.example >>>> dubious.example._mail._rep.scorekeeper.example >>>> >>>>for "type"-specific queries. >>> >>>OK by me, although it'll be interesting to define the set of names. >> >>Maybe consider all-digit "names": dubious.example._80._rep.scorekeeper.example ... > >My intention using subdomains was so that you could have different opinions of, say, mail from a domain vs. web sites hosted at the domain. I don't understand what numbers would do other than be opaque. Sorry, I was being obscure. TCP ports instead of their names. 80 == HTTP, 25 == SMTP, and so on. --Paul Hoffman, Director --VPN Consortium From dotis@mail-abuse.org Wed Aug 11 17:11: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 A5F1F3A696D for ; Wed, 11 Aug 2010 17:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.339 X-Spam-Level: X-Spam-Status: No, score=-106.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 qStpyBRjI1WX for ; Wed, 11 Aug 2010 17:11:30 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id AE16A3A687B for ; Wed, 11 Aug 2010 17:11:30 -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 ED4AFA94B27 for ; Thu, 12 Aug 2010 00:12:00 +0000 (UTC) Message-ID: <4C633C50.3050008@mail-abuse.org> Date: Wed, 11 Aug 2010 17:12:00 -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: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> In-Reply-To: <4C631989.1030203@att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 00:11:31 -0000 On 8/11/10 2:43 PM, Tony Hansen wrote: > I feel comfortable with the direction this is heading. However, I'd > change the type specific queries to use something like > > dubious.example._web._rep.scorekeeper.example > dubious.example._mail._rep.scorekeeper.example While we are selecting the color of the shed... What problem will this service resolve for the web? For example, it is not apparent how will this can block an exploit on some user's web page without blocking the entire domain. What problem will this service resolve for email? Nearly all large providers emit a fair amount of malicious content due to the number of compromised accounts. Bad actors also exchange benign content among their thousands of owned domains, and then one-by-one, after obtaining good ratings, launch blitzkrieg attacks. Bot-nets normally win in a reactive Whack-a-Mole game, especially when they can also hold back your mallet by DDoSing the service. How will this seemingly exposed service be defended against abuse? The greatest difficulty ahead in taking the naive approach of "see what works" is that publishing ratings in DNS does not share the information needed to defend blocking decisions. The imagined magic fully automated rating schemes full of secret sauce is not going to work in a world of bot-nets. Once a domain has shown itself malicious, over time, the domain must remain blocked, otherwise this would allow the kriegspiel to continue unabated. Supporting such a domain blocking effort will not be inexpensive either, for obvious reasons. Solve the difficult problem first, the support of domain blocking decisions. Do this before deciding on how to publish the results of the information. Use of DNS Response Policy Zones will not require any other information to be published in DNS, provided the policy returns NXDOMAIN. This approach also will not require any changes to be made in MTAs or web browsers. -Doug From fergdawgster@gmail.com Wed Aug 11 17:13:00 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 93C743A687B for ; Wed, 11 Aug 2010 17:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 P8+T1NidFPtj for ; Wed, 11 Aug 2010 17:12:59 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 43B183A67B7 for ; Wed, 11 Aug 2010 17:12:59 -0700 (PDT) Received: by wwf26 with SMTP id 26so5714902wwf.1 for ; Wed, 11 Aug 2010 17:13:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=k5kQWAaoOLKqAqRnzsvaj+hGKHdVqzjrdt47B+jk2Ls=; b=NeAWnOeloIeqi4WObohW6va5rnzZ0glqDZ5x5lvf83BGAQin2NoDnc/JpNS1L/7wiK 7LP/IoOqnjMF+BM+Xhs2aEbNm1SuG642D7kWASOSQgEESksZSw9iNv+TkUsRTR0bVd7D N0PzvqemJYOgwkhcPVJ4V3q/BDyhIdoTOLJEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VQfodZKJYPplN3iwQp2aKbZaqic9b03ugSj55QjZ3Ud/tqDngw2EglDmbLbzK4frWF AoF7SztrS7pTw9847ZvZvPCJneOPi8uBjSHuy5FXsoMZ7/p8WJ/SowUrO6dUFegom9zC zasWFlwZUAi6Vx+ACM6iEhl1Ijw8+HFBIWtkw= MIME-Version: 1.0 Received: by 10.216.59.131 with SMTP id s3mr17208140wec.71.1281572014982; Wed, 11 Aug 2010 17:13:34 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Wed, 11 Aug 2010 17:13:34 -0700 (PDT) In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> Date: Wed, 11 Aug 2010 17:13:34 -0700 Message-ID: From: Paul Ferguson To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 00:13:00 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Aug 11, 2010 at 5:06 PM, Paul Hoffman wrote: >>> >>>Maybe consider all-digit "names": >>>dubious.example._80._rep.scorekeeper.example ... >> >>My intention using subdomains was so that you could have different >>opinions of, say, mail from a domain vs. web sites hosted at the domain. >>I don't understand what numbers would do other than be opaque. > > Sorry, I was being obscure. TCP ports instead of their names. 80 =3D=3D H= TTP, > 25 =3D=3D SMTP, and so on. > Then I suppose you would also have to support wildcards for domains which are 100% malicious, regardless of port? - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMYzyoq1pz9mNUZTMRAsD6AKCoe0qbZRtTkVLpXeK0p10zCTwm4ACgrNft CzQrgpDrDhqxijzrkuf0t30=3D =3Dt5vN -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From stephen.farrell@cs.tcd.ie Wed Aug 11 17:20:37 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 93E313A6842 for ; Wed, 11 Aug 2010 17:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.899 X-Spam-Level: X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 eDYDcL+FL8Zj for ; Wed, 11 Aug 2010 17:20:36 -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 9481C3A687B for ; Wed, 11 Aug 2010 17:20:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id AA98A3E408F; Thu, 12 Aug 2010 01:21:10 +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=1281572470; bh=VQB7ssL0d18Z4C 68UDAChbsGcCtadee/0XotDw9PXsA=; b=QtRwk4KUvQnlJ5qtleqPFikBYz46KS whE2NZTJNYiUfXmrsL63i1vf5aPfxW36LWP4TGMxETt2j0aTeieMk6wDsM7VwOoy 7vpqhzmlkXnuudW9arVTmJtdBaVSUH1PLZh5mPYs3+W9vhDBZ0hTAF9GIw+8xZtF 0+T7X60kSu5UFpxWCzvfwcZRNPr4g+urWyOKuPSw5OkEbNlO0Rn7Ou4JKiJMUPfp V/pOn4kLOV0Wt9pVH6dSJRGAwrdPJ44tMbOla4py6LtxtYmr7bwH452WF+d6qdy1 Hgq2RAwwvhvgZT7ypwo5kAjAUd5dtkTZkWkgZyc8e9zWCknoos7fLWUg== 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 ZyJi87kZdIPd; Thu, 12 Aug 2010 01:21:10 +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 0603B3E408C; Thu, 12 Aug 2010 01:21:09 +0100 (IST) Message-ID: <4C633E72.30002@cs.tcd.ie> Date: Thu, 12 Aug 2010 01:21:06 +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: "John R. Levine" References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.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] A sketch of a small query reputation system 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, 12 Aug 2010 00:20:37 -0000 On 12/08/10 00:49, John R. Levine wrote: > My intention using subdomains was so that you could have different > opinions of, say, mail from a domain vs. web sites hosted at the domain. > I don't understand what numbers would do other than be opaque. So just to question the idea of domains for a moment. Are domains the right/only things for which we'd like to enable folks to query reputation? For example, what about specific email addresses? Or perhaps more reasonably, since there are databases, WiFi BSSIDs? (I would have used URIs as an example, but didn't since they queries containing full URIs would have encoding issues that would just be distracting for now.) Put another way: why should the interesting part of the query have to include a domain name that exists in the DNS? S. From paul.hoffman@vpnc.org Wed Aug 11 17:38:26 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 787F93A687B for ; Wed, 11 Aug 2010 17:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.092 X-Spam-Level: X-Spam-Status: No, score=-100.092 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 TYrEH7nKzZ03 for ; Wed, 11 Aug 2010 17:38:25 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id BE8883A67B7 for ; Wed, 11 Aug 2010 17:38:25 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7C0cfUu059781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Aug 2010 17:38:42 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> Date: Wed, 11 Aug 2010 17:38:39 -0700 To: Paul Ferguson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 00:38:26 -0000 At 5:13 PM -0700 8/11/10, Paul Ferguson wrote: > > Sorry, I was being obscure. TCP ports instead of their names. 80 == HTTP, >> 25 == SMTP, and so on. >> > >Then I suppose you would also have to support wildcards for domains which >are 100% malicious, regardless of port? Sure. Port 0 works fine for that (ignore the current registration in the IANA database; it is a mistake). --Paul Hoffman, Director --VPN Consortium From johnl@iecc.com Wed Aug 11 18:15: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 CC42D3A688F for ; Wed, 11 Aug 2010 18:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.78 X-Spam-Level: X-Spam-Status: No, score=-109.78 tagged_above=-999 required=5 tests=[AWL=1.419, 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 rpQ5XeEtXyOu for ; Wed, 11 Aug 2010 18:15:01 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id F06D33A67DB for ; Wed, 11 Aug 2010 18:14:59 -0700 (PDT) Received: (qmail 98881 invoked from network); 12 Aug 2010 01:15:36 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Aug 2010 01:15:36 -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=k1008; olt=johnl@user.iecc.com; bh=y13M0qX5WINwt/3KzKNT/JueLcGBKTUPuZDs4/bMQm8=; b=A8GM6PQqG38n4R3YjDroYC6ezWICvi/nsFvEfOdUFQ5oV0MUOveYtvlvMkeSFwPc542HSZjKqEE2Feie5svZUyt/x1KtvoN8RcZ6eD2JsN3chT2vG3QcA07/h9BpGwX6xFES8N7dxI32Bq9XExFhVWWR1Mmq3N3bMgvonQxSlJw= Date: 12 Aug 2010 01:15:36 -0000 Message-ID: <20100812011536.52399.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] A sketch of a small query reputation system 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, 12 Aug 2010 01:15:08 -0000 >> > dubious.example._web._rep.scorekeeper.example >> > dubious.example._mail._rep.scorekeeper.example >> OK by me, although it'll be interesting to define the set of names. > I think I agree. Why not leave it to the reputation provider to do > this, making it explicit (or >general, by not using them) what the > *ahem* domain of the reputation is, and save us an IANA > consideration? I think the point of _web and _mail was so that one could design provisioning systems with a known set of buttons. If it's per-provider, better to make it part of the domain name to the right of the _rep. But this is a nit, we can worry about it whenever. How about the model of the triplet of score,confidence,NAICS ? R's, John From stephen.farrell@cs.tcd.ie Wed Aug 11 18:23:37 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 9C7A03A6966 for ; Wed, 11 Aug 2010 18:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.869 X-Spam-Level: X-Spam-Status: No, score=-102.869 tagged_above=-999 required=5 tests=[AWL=-0.270, 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 c3DXwMj6kJGI for ; Wed, 11 Aug 2010 18:23:36 -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 A31783A67E5 for ; Wed, 11 Aug 2010 18:23:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0A3B43E407F; Thu, 12 Aug 2010 02:24:11 +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=1281576250; bh=aiRQ/EtXQPqcdc vGHs3LmjQg9fwheVa/98cmffq2oQk=; b=mX4rOViZ9wBJ8cB/tSPhJJ9aEngU8Q hJ1FRE0FE30cWPo9Rh2QNWRDL9JS5iigYnkby9yuAKSvQa6b6+uFg6RvT8+R57GF 5XJf+cpMDKD9GuQUDieAYSlulGDdVarrYbnLnz6UBK/SbHELz7JAmXW+RENKMw3K joJ2dJrz1/C0mMD7IbPRCm29fzA1CVIGxVACawBGKlqpKkMpStvuOi9nzOVguNVo niLcxrrhNpetn8q5cG/wb778cRNDR2MXwuAlOtH6qI8SCJR3QYiWz+lhILAtDCQO e2koP/g6oQqmXToVPkdt91ShuUvWY1DzZ5LJfFCqPYl6SFl+E2A+RS5w== 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 plo4AivHM-Lj; Thu, 12 Aug 2010 02:24:10 +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 531FD3E4074; Thu, 12 Aug 2010 02:24:09 +0100 (IST) Message-ID: <4C634D2C.2010109@cs.tcd.ie> Date: Thu, 12 Aug 2010 02:23:56 +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: John Levine References: <20100812011536.52399.qmail@joyce.lan> In-Reply-To: <20100812011536.52399.qmail@joyce.lan> 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] A sketch of a small query reputation system 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, 12 Aug 2010 01:23:37 -0000 On 12/08/10 02:15, John Levine wrote: > How about the model of the triplet of score,confidence,NAICS ? Score and confidence are fine. The NAICS part is, I have to assume, a joke. S. From johnl@iecc.com Wed Aug 11 19:09:35 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 D40BF3A685E for ; Wed, 11 Aug 2010 19:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.804 X-Spam-Level: X-Spam-Status: No, score=-109.804 tagged_above=-999 required=5 tests=[AWL=1.395, 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 WYeGgAI7-z1f for ; Wed, 11 Aug 2010 19:09:34 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 8AE913A67D4 for ; Wed, 11 Aug 2010 19:09:34 -0700 (PDT) Received: (qmail 18651 invoked from network); 12 Aug 2010 02:10:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=7rBpmJ6Izds5XHeGdJO+5bb4bOI5+5AuhoZ56HXc1Kc=; b=Xd4CMtPYIxcGUVPzREM1yqSZaWyg7Vt20fFNFrF2HZiDkv2+4/I5y+Gfulh78H0ZTvIg0FnVTUTx+dpEUGTmzOP5kQynaEILzVTnrVWQ9WT73pcl9hd8eUGO+QQ+MPyTqjkOIeRX8ra9N9USQ1eFaFWzAfhN+BuzYgO4KbxjjdY= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Aug 2010 02:09:47 -0000 Date: 11 Aug 2010 22:10:09 -0400 Message-ID: From: "John R. Levine" To: "Stephen Farrell" In-Reply-To: <4C634D2C.2010109@cs.tcd.ie> References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 02:09:35 -0000 > Score and confidence are fine. The NAICS part is, I have to assume, a > joke. My, aren't we provincial. As I said, if you have a better suggestion for a set of widely used and freely available codes to identify types of organizations, I'd be happy to use something else. But NAICS is what people use. R's, John From johnl@iecc.com Wed Aug 11 19:14:14 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 7F3573A67E5 for ; Wed, 11 Aug 2010 19:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.828 X-Spam-Level: X-Spam-Status: No, score=-109.828 tagged_above=-999 required=5 tests=[AWL=1.371, 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 85YJBs+ArC+t for ; Wed, 11 Aug 2010 19:14:12 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 71A6E3A681A for ; Wed, 11 Aug 2010 19:14:12 -0700 (PDT) Received: (qmail 20136 invoked from network); 12 Aug 2010 02:14:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=hZhnXqcyvPvRoDviEHih3SPl33Lvj2Nx8rnncYtXoCk=; b=gFpxDEPEo1/4Wqmbcigf5EVXx3ieGNrlJvb9QchwTkifTXDK5MeYpTNksZpjVNfOqtDsyEGIq73gItPMGFP6AAhCJrJMZhZjHoWU+3k4BzQzFUHKVafDNYQrdfjVvAL2BUL6kW5wHa+GdkoZMhUNC+cptd7X90Jle7Anmfua68M= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Aug 2010 02:14:26 -0000 Date: 11 Aug 2010 22:14:48 -0400 Message-ID: From: "John R. Levine" To: "Stephen Farrell" In-Reply-To: <4C633E72.30002@cs.tcd.ie> References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> <4C633E72.30002@cs.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 02:14:14 -0000 > Put another way: why should the interesting part of the query > have to include a domain name that exists in the DNS? Mostly to keep the scope of the project finite. (And, of course, it does say "domainrep" up there on the subject line.) If people wanted to publish reputation for IP addresses, it'd be obvious enough how to adapt the rDNS encoding to do that. I suppose you could encode other stuff, but once you get past domains and IPs, it appears to me that the utility rapidly drops off. R's, John From msk@cloudmark.com Wed Aug 11 21:48: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 488B728C0DB for ; Wed, 11 Aug 2010 21:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.415 X-Spam-Level: X-Spam-Status: No, score=-103.415 tagged_above=-999 required=5 tests=[AWL=-0.816, 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 DjtCcHjEVRll for ; Wed, 11 Aug 2010 21:48:06 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id F2FD428B56A for ; Wed, 11 Aug 2010 21:48:05 -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, 11 Aug 2010 21:48:42 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 11 Aug 2010 21:48:41 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5tsRXIbbuQQGZT+6r34AP5hFk0QAIpt/A Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.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] A sketch of a small query reputation system 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, 12 Aug 2010 04:48:07 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Paul Hoffman > Sent: Wednesday, August 11, 2010 5:39 PM > To: Paul Ferguson > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > >Then I suppose you would also have to support wildcards for domains > which > >are 100% malicious, regardless of port? >=20 > Sure. Port 0 works fine for that (ignore the current registration in > the IANA database; it is a mistake). You could query twice, once with the port-specific prefix and once without,= I suppose. (Or in the opposite order perhaps.) This gets shortened if th= ere's an understanding with the reputation provider that it does/doesn't do= port-specific stuff. From msk@cloudmark.com Wed Aug 11 21:50:37 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 9C5113A695A for ; Wed, 11 Aug 2010 21:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.406 X-Spam-Level: X-Spam-Status: No, score=-103.406 tagged_above=-999 required=5 tests=[AWL=-0.807, 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 kT5eUZMJLt5O for ; Wed, 11 Aug 2010 21:50:36 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id D11723A6952 for ; Wed, 11 Aug 2010 21:50:36 -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, 11 Aug 2010 21:51:13 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 11 Aug 2010 21:51:12 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5vRXoV8loQXNCTLisHLRBsmQonQAHKuEA Message-ID: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> In-Reply-To: <4C634D2C.2010109@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 04:50:37 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Stephen Farrell > Sent: Wednesday, August 11, 2010 6:24 PM > To: John Levine > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > On 12/08/10 02:15, John Levine wrote: > > How about the model of the triplet of score,confidence,NAICS ? >=20 > Score and confidence are fine. The NAICS part is, I > have to assume, a joke. There has been some interest in the idea of conveying what kind of organiza= tion is, or appears to be, associated with a domain. How that's determined= is unspecified, but I guess that would be up to the reputation provider an= yway. If people really hate the idea of NAICS here, maybe the reputation provider= is free to come up with its own set of names or codes that's used between = it and its consumers, and we just have to create a syntax that works. From johnl@iecc.com Wed Aug 11 22:17: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 D5F7E3A697B for ; Wed, 11 Aug 2010 22:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.851 X-Spam-Level: X-Spam-Status: No, score=-109.851 tagged_above=-999 required=5 tests=[AWL=1.348, 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 O9dLkP593kso for ; Wed, 11 Aug 2010 22:17:18 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 982A93A6990 for ; Wed, 11 Aug 2010 22:17:16 -0700 (PDT) Received: (qmail 86204 invoked from network); 12 Aug 2010 05:17:52 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Aug 2010 05:17:52 -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=k1008; olt=johnl@user.iecc.com; bh=aWULI+vRIjD4tGSR6nhZkjdjj4AKIJ1IxRaBbCfCJec=; b=s9larGrHpUhZIdx6BD8TKBiVZNcU/1FUjH+fBn7M/T4R0kh4YiqD/lS9wfXgrV587MLfmp+mMJJUPEZO08bmBrOEsyiE15hPeXPrimroNBA7QfPnSwmupk5D8+Mpt6LByIhV8Gn+pXEEDiiclHFb4R+Oi5hMM6x/+rr+qCpKg4k= Date: 12 Aug 2010 05:17:51 -0000 Message-ID: <20100812051751.11251.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] A sketch of a small query reputation system 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, 12 Aug 2010 05:17:23 -0000 >If people really hate the idea of NAICS here, maybe the reputation >provider is free to come up with its own set of names or codes that's >used between it and its consumers, and we just have to create a >syntax that works. Ewww. If I want to whitelist mail from banks, or blacklist mail from mortgage brokers,, it sure would be nice to be able to configure in categories 5221 and 52231 rather than having to try and figure out what each provider's names for them are. I think the only objection I've seen to NAICS seems to be that it's published by the US government, not that the set of categories won't do the job. For anyone who's interested in this, I encourage you to take a look at the categories and see if you think they're reasonable, and if not, suggest something that would work better. http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2007 R's, John PS: The ISO 3166 list on which ccTLDs are based was until recently managed by DIN in Berlin. Nonetheless, it is not my impression that the DNS is secretly controlled by the Germans, and you know who I mean. From fergdawgster@gmail.com Thu Aug 12 00:13:37 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 0E9283A69D4 for ; Thu, 12 Aug 2010 00:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 2A6CyqWEjIJ3 for ; Thu, 12 Aug 2010 00:13:35 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 7ECD33A69D3 for ; Thu, 12 Aug 2010 00:13:35 -0700 (PDT) Received: by wwj40 with SMTP id 40so953023wwj.13 for ; Thu, 12 Aug 2010 00:14:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type:content-transfer-encoding; bh=hnIjXWqjMMLgOXg+sVCn3NFFdCeXU7YdHgajO86wB2o=; b=W5E9y8nMx4R2IZo+pCA9otrd4h4SokxzBDPsWaxvRHMIlv+1w++17euMxFgnDtix6R PPS5e3duZ8ze0Ec6wVsnHKEwjJGdMN8m7Xe1iczprAcDddaauT9Ww9Q8A8mb61w1dEFn JeV3Gvdde8kIqZSMmg1Doy5JJTobiUbZlQlRs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=J4MXsGf0OjnnJ2OTWgtwcTA/V+tmBoDrZtuhTGE9Dt3LkmXmZDhUl6R9eGRmXvVO75 2QKToq3k6GV7ZQ+9aP6FmLPGUhX4qSoR6vIkWAXC0F0bI0rWIQCZ+yCbIvy31oXULqDo Zoe5YX5RZWmIbWl3xVzwihM+4fZJwTHhdjGto= MIME-Version: 1.0 Received: by 10.216.28.213 with SMTP id g63mr6332688wea.71.1281597251842; Thu, 12 Aug 2010 00:14:11 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Thu, 12 Aug 2010 00:14:11 -0700 (PDT) Date: Thu, 12 Aug 2010 00:14:11 -0700 Message-ID: From: Paul Ferguson To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [domainrep] Multi-Party [Web of Trust] XML Queries 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, 12 Aug 2010 07:13:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So, I was contacted by several parties who expressed interest in my earlier mention of IODEF -- or something like it -- as a possible information exchange mechanism. I say "something like it" since it is simply nothing more than an extensible XML query/response mechanism to exchange information. It seems to me that, in contrast to trying to cram more stuff into DNS, there is an alternative -- a "web" or multi-party XML query/response entities. This makes a lot of sense to me -- there is no need to define limitations in this scheme, since each entity determines on their own with whom they will query or respond. In this scheme, the only work to be done is to determine how that data would be encoded, any particular scalar ratings, etc. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMY58iq1pz9mNUZTMRAtTxAKDh0u9U58Br91NHhZEu7X2J6ukGTwCfV8ux 2oBw3qGRMOT8LnK/aL2OGpg=3D =3Dwj1D -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From leifj@mnt.se Thu Aug 12 01:09: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 1CADE3A69ED for ; Thu, 12 Aug 2010 01:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ECUlXld7JezA for ; Thu, 12 Aug 2010 01:09:38 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id C928F28B23E for ; Thu, 12 Aug 2010 01:09:36 -0700 (PDT) Received: from [192.36.125.216] (dhcp.pilsnet.sunet.se [192.36.125.216]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o7C8ABL8012851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 12 Aug 2010 10:10:13 +0200 (CEST) Message-ID: <4C63AC63.7000309@mnt.se> Date: Thu, 12 Aug 2010 10:10:11 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre MIME-Version: 1.0 To: domainrep@ietf.org References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 08:09:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/12/2010 02:38 AM, Paul Hoffman wrote: > At 5:13 PM -0700 8/11/10, Paul Ferguson wrote: >>> Sorry, I was being obscure. TCP ports instead of their names. 80 == HTTP, >>> 25 == SMTP, and so on. >>> >> >> Then I suppose you would also have to support wildcards for domains which >> are 100% malicious, regardless of port? > > Sure. Port 0 works fine for that (ignore the current registration in the IANA database; it is a mistake). This seems to assume that the port is suitable as an endpoint identifier. I'm not sure that is true (anymore). For instance were I to build a reputation service for a set of SAML relying parties the service endpoint would be a URI. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxjrGMACgkQ8Jx8FtbMZne3iwCeLz5AzGQMOVcbLeK5KBDQF/C1 xtMAn1c0Wxsb3dIpfD4d0hVgonOm0cdl =XZ7m -----END PGP SIGNATURE----- From stephen.farrell@cs.tcd.ie Thu Aug 12 01:30:37 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 9A5603A69F0 for ; Thu, 12 Aug 2010 01:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.844 X-Spam-Level: X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=-0.245, 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 ncT7hH2POzFX for ; Thu, 12 Aug 2010 01:30:36 -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 DC8C53A68DA for ; Thu, 12 Aug 2010 01:30:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2A3183E407F; Thu, 12 Aug 2010 09:31:10 +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=1281601870; bh=vFck64bYk6efkr uLbSQ/r2O18q27j67BPmyL8mRuYxU=; b=LC4KljWKJg0CEE7D5nLE2zf3U/jfl+ tBYWtXwhoVs8fF82JDHXvIl+ZGss13WXJSIOPhH0/HO+P9EiahfTwbBECVBA4fBX ldhC47VtSK3WHYqhWyAYgDEo4TfUZCp/10DAPaGCKufi0ycylV1zmHQiCaCzZ8Pa Qe7LLbeQHI3PyTAQ1u9vAdDjzfpzmdXtc6Hfp7PfpKZ5zn+YxqWhRWQp+HNc+oaZ bpta4LftaL2sMDMccU2JUGD3JjEAZToAu1t0UxC4K3rE3x1jGnacCQUzTLNAUzmr rlV1fG14YnyCkDf+dWYRe3MCHk7oGSlNPmBt0hztZUHjD1nCgs00byOg== 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 b2w4CyiQvvjH; Thu, 12 Aug 2010 09:31:10 +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 DC79A3E407D; Thu, 12 Aug 2010 09:31:09 +0100 (IST) Message-ID: <4C63B14C.5060202@cs.tcd.ie> Date: Thu, 12 Aug 2010 09:31:08 +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: "John R. Levine" References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 08:30:37 -0000 On 12/08/10 03:10, John R. Levine wrote: >> Score and confidence are fine. The NAICS part is, I have to assume, a >> joke. > > My, aren't we provincial. Apparently you are:-) > As I said, if you have a better suggestion for a set of widely used and > freely available codes to identify types of organizations, I'd be happy > to use something else. But NAICS is what people use. People where? I think that were this an appropriate time to get into that detail then the onus would be on you to show that this could be acceptable outside of NA and that its coverage is appropriate for the Internet and not just NA. The issue for me is not mainly its origin, its that its a scheme for industry (which doesn't cover everything that may possess a reputation score), and I don't believe that all worldwide industry is organised along north American lines. I guess some folks might have an issue with change control for the scheme residing with a national government, but that's less of a concern for me. In any case, this is all extremely premature. I think you first need to say why an organisation classification value is generally useful before its encoding becomes an issue. Such a value may or may not be a good idea generally, I don't know. I can see why it'd be useful for mail and maybe web services for some people but I guess that it'd lead to communications being unncessarily blocked in some cases, at least my experience with nanny web filters is that they all get this wrong sometimes. Secondly, this seems to represent a leakage of the secret sauce from the server to the client - if organisation type is sent back, then why not any other element of the secret sauce? Seems like a slippery slope. Could be a good or a bad slope to slide down though. S. > > R's, > John > From stephen.farrell@cs.tcd.ie Thu Aug 12 02:52:26 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 0BADB3A684D for ; Thu, 12 Aug 2010 02:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=-2.000, 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 hy-w+ZCwdYLT for ; Thu, 12 Aug 2010 02:52:25 -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 9C13A3A68D2 for ; Thu, 12 Aug 2010 02:52:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 0A42E3E407F; Thu, 12 Aug 2010 10:53:00 +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=1281606779; bh=cm4FTWKyKHBumh vHQJmYUA2uCBD3abveL7p9UeA3mtA=; b=Ffs2xpJRwmJ1fVFwXU36L1efddICPt NtRvhI1l3dVYetD98Bw3lCTZFr2zeRjqc154AzDxBtvzBCvPxZPj+gS4jp5zOtmf NtzxKNOjofks151jj2t/kyWi613ErO64w4GINr1E/nlvlW+IV1DD/Z57KT23fkhC X5/6Xg6cfj7w0oYGI3iWiWw87RXH1pYkntZowqRmkAPhQkB2tfwb4CK7ggto+tam hG1jeGPjyW0vkwMKKnlVrPE1urw3Q3qcDUR7Hoqrx4VakgLTdRusF0eO61X2l+qD 039PIhm+Qp8qi4NvFPl8p/lmSOUtW+S/hJm8+cSwTuvUdc8sf15GdFaA== 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 NO4M+H5Ysyz8; Thu, 12 Aug 2010 10:52:59 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8FDDD3E407C; Thu, 12 Aug 2010 10:52:59 +0100 (IST) Message-ID: <4C63C479.9070707@cs.tcd.ie> Date: Thu, 12 Aug 2010 10:52:57 +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: "John R. Levine" References: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> <4C633E72.30002@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 09:52:26 -0000 On 12/08/10 03:14, John R. Levine wrote: >> Put another way: why should the interesting part of the query >> have to include a domain name that exists in the DNS? > > Mostly to keep the scope of the project finite. Sure. We need to get there after we've explored it a bit. > (And, of course, it > does say "domainrep" up there on the subject line.) Right. That is the central, but not necessarily the only, idea. > If people wanted to publish reputation for IP addresses, it'd be obvious > enough how to adapt the rDNS encoding to do that. Right. I would guess BSSIDs would be easy enough via an ENUM like mechanism too. > I suppose you could > encode other stuff, but once you get past domains and IPs, it appears to > me that the utility rapidly drops off. What's not clear is whether that's because of limitations due to wanting to encode everything into DNS or for some other reason. S. From stephen.farrell@cs.tcd.ie Thu Aug 12 04:50: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 4CE543A69FD for ; Thu, 12 Aug 2010 04:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, 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 UWqa6oGjO2tj for ; Thu, 12 Aug 2010 04:50:16 -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 A1EE53A68FA for ; Thu, 12 Aug 2010 04:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 265F43E408A for ; Thu, 12 Aug 2010 12:50:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1281613851; bh=8wK+zPtnhCWj0ql2xMsapzON 11exeEfLzkAgmoa7QA0=; b=ZoqsVjbNw2wwXHZVXTJDRYHfItagYAdHkga4NZSJ ubt++Lt5qlEabUUBDM4h80MPGcaxz9a70njx9mX68np0WXzHb/lnXGfeP52PUhgE 06eLYXOT3667tA37uQkOSMnIDTu4hDiZCOSV2gN3eDjBTIR+X5ckagivvmYJ0UiT OTxqSaGbe2+oz9yxQRkpYa0MOAo00cFxTOgN7SVXBOio4GGqvuyB+WP8c1r83MEG olnQcwG2aZVevx3bNJcSo0tDniv7icZq6dK2qjIx9KIR6SFuUlagXpSv9j0RYqp5 BQEGNs8Bsgu2YHRYu01UcAagsG5KKY6bPvkcjOQyNrXo+Q== 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 NrH8SYzzi7b5 for ; Thu, 12 Aug 2010 12:50:51 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id EEDA83E407F for ; Thu, 12 Aug 2010 12:50:50 +0100 (IST) Message-ID: <4C63E019.6090606@cs.tcd.ie> Date: Thu, 12 Aug 2010 12:50:49 +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" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [domainrep] safe browsing thing & privacy 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, 12 Aug 2010 11:50:18 -0000 I was wondering how that safe browsing thing in FF works and found a relevant link. [1] I guess its a slightly different problem, (its a blacklist), but given that they manage to make it work its interesting I think. Presumably one could do almost the same things to talk to a reputation provider. We should probably note the privacy considerations - this works by sending chunks of lists to clients, so that clients don't have to send URLs to the server. I wonder if the protocol we're working towards would also need to (be able to) operate in some equally privacy-friendly manner? (DNS would probably be ok in that respect, but an angle-bracket approach might have to do lots more.) S. [1] http://code.google.com/p/google-safe-browsing/wiki/Protocolv2Spec From johnl@iecc.com Thu Aug 12 07:39:11 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 C32B23A6407 for ; Thu, 12 Aug 2010 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.873 X-Spam-Level: X-Spam-Status: No, score=-109.873 tagged_above=-999 required=5 tests=[AWL=1.326, 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 rE-t4qd6e+yQ for ; Thu, 12 Aug 2010 07:39:10 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 5DD093A68C3 for ; Thu, 12 Aug 2010 07:39:10 -0700 (PDT) Received: (qmail 83409 invoked from network); 12 Aug 2010 14:39:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=mYRGCZsKaQggDatjK80tb6NGORUExGzkMYXNOyve760=; b=MrIDACSVHBM+5FT51ltpK8NRqGZnf74WsmfOMcVOkCw8j4BQM27/+uZgFURcOMA5nawAY+3oem6Su377b+9Du15ksKMcTsm/6DRXfnwQb6hW6Amo//jzGAg299Tx+0Ohu8zi7AOrzpltooPsyTJIUAVAqI9HAVhZDHY8AMDVWtM= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Aug 2010 14:39:24 -0000 Date: 12 Aug 2010 10:39:46 -0400 Message-ID: From: "John R. Levine" To: "Stephen Farrell" In-Reply-To: <4C63B14C.5060202@cs.tcd.ie> References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 14:39:11 -0000 > In any case, this is all extremely premature. I think you > first need to say why an organisation classification value > is generally useful before its encoding becomes an issue. Sigh. As I think I've said at least three times now, some mail systems may want to handle incoming mail differently if they know it's from a particular kind of organization, with banks and governments being the usual examples. This isn't hypothetical. When we were talking about this at DAC, people who handle rather a lot more mail than you or I do said this would be useful. R's, John From stephen.farrell@cs.tcd.ie Thu Aug 12 07:50:40 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 D573B3A6885 for ; Thu, 12 Aug 2010 07:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 UbAUiOqrYtDE for ; Thu, 12 Aug 2010 07:50:38 -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 0CBF53A67C2 for ; Thu, 12 Aug 2010 07:50:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E99F93E408A; Thu, 12 Aug 2010 15:51:12 +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=1281624672; bh=d0VhVM+9uONtJy kXsqY3ugrrU8SxvO60CXxA18Y8r9w=; b=4Jp0FpXldiCeDbn1jdUEpqBRYR1KRZ zSdP+Lto+U2w8bUh5i7dJVzVdb+X6Mo5wc5pv8z0M8L/MWrO5qlSbIwVuiv/QcdL vfwcDIyC6N0WvIUMDfibTUC/HLzLou63FdVSCFu7DSw+8W8/b1ghWRl2Ijbw1f9G ZN2idGIOrek5z8CtpB3hriiVFC+REoeGkcZUv6U9znAwMuxY758t6ls8AAm4AiYS eXfC1eAs9VviUBe+4+HI+3t9MAu26GwGdaHxOgCH039b5HyjIDbYYGKQ2kpEOBFb W/4MkWxsILsx4m4oIQaRcadL0EU5hg0c4BVGQ0gAhYYue3mCt623sD9w== 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 b4dw9HomW8nh; Thu, 12 Aug 2010 15:51:12 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 821453E406C; Thu, 12 Aug 2010 15:51:12 +0100 (IST) Message-ID: <4C640A5F.6080008@cs.tcd.ie> Date: Thu, 12 Aug 2010 15:51:11 +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: "John R. Levine" References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 14:50:40 -0000 On 12/08/10 15:39, John R. Levine wrote: >> In any case, this is all extremely premature. I think you >> first need to say why an organisation classification value >> is generally useful before its encoding becomes an issue. > > Sigh. As I think I've said at least three times now, some mail systems > may want to handle incoming mail differently if they know it's from a > particular kind of organization, with banks and governments being the > usual examples. Yes, you have asserted that. But not said why its always or even frequently relevant, i.e. what would I do with the information that dance.example.com is probably an ok ballet company? > This isn't hypothetical. When we were talking about this at DAC, people > who handle rather a lot more mail than you or I do said this would be > useful. I don't doubt that. However, that doesn't mean that an industry code of any sort is something that a generic Internet standard for domain reputation should necessarily include as part of every query response. It could be that there are just a couple of interesting classes of domain for which this is useful, and that the reputation supplier might offer a different interface for querying those. I don't know, but I'd hate to burden every client with having to understand whatever classification system were to be used and force every reputation vendor to classify all domains accordingly. S. > > R's, > John > From paul.hoffman@vpnc.org Thu Aug 12 07:52: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 DD08E3A6885 for ; Thu, 12 Aug 2010 07:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.723 X-Spam-Level: X-Spam-Status: No, score=-99.723 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 c+70qm5gnbAe for ; Thu, 12 Aug 2010 07:52:27 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 1897D3A67C2 for ; Thu, 12 Aug 2010 07:52:27 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7CEqNGj010494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2010 07:52:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> Date: Thu, 12 Aug 2010 07:52:21 -0700 To: "John R. Levine" , "Stephen Farrell" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 14:52:28 -0000 At 10:39 AM -0400 8/12/10, John R. Levine wrote: >>In any case, this is all extremely premature. I think you >>first need to say why an organisation classification value >>is generally useful before its encoding becomes an issue. > >Sigh. As I think I've said at least three times now, some mail systems may want to handle incoming mail differently if they know it's from a particular kind of organization, with banks and governments being the usual examples. > >This isn't hypothetical. When we were talking about this at DAC, people who handle rather a lot more mail than you or I do said this would be useful. An example that was given was "if I'm in a grey area, I would drop mail from a tire manufacturer before I would drop mail from a bank or government". Further, two of the reputation services said that they had customers who already bought this information from them. That makes it sound useful, even if you personally don't understand the reason why people would buy it. --Paul Hoffman, Director --VPN Consortium From johnl@iecc.com Thu Aug 12 08:02:35 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 BD25028C101 for ; Thu, 12 Aug 2010 08:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.894 X-Spam-Level: X-Spam-Status: No, score=-109.894 tagged_above=-999 required=5 tests=[AWL=1.305, 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 naaJH5ySPqI9 for ; Thu, 12 Aug 2010 08:02:30 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 44F8A28C0F9 for ; Thu, 12 Aug 2010 08:02:30 -0700 (PDT) Received: (qmail 97680 invoked from network); 12 Aug 2010 15:03:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=9GVBt0ZArgH/abf2apTImnSTgHAQvK4sIZANaB8+7rg=; b=Vownnmb7zzrNXPymnkvIyYFuSs4TC/LQqoe6C1L62F1cZGMiCqulS6z8/xNCqJz1knjcUh3B24x5z8vPx4aaJQ75ekIpN47Aho/rHAJCvagyRgXHyL/AqkuYEwls2la13oBKWkxmjRCzz7apx3tIBRLEkZkztTlNTBWs8lZBhKM= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Aug 2010 15:02:45 -0000 Date: 12 Aug 2010 11:03:06 -0400 Message-ID: From: "John R. Levine" To: "Stephen Farrell" In-Reply-To: <4C640A5F.6080008@cs.tcd.ie> References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C640A5F.6080008@cs.tcd.ie> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 15:02:35 -0000 > It could be that there are just a couple of interesting classes > of domain for which this is useful, and that the reputation > supplier might offer a different interface for querying those. > I don't know, but I'd hate to burden every client with having > to understand whatever classification system were to be used > and force every reputation vendor to classify all domains > accordingly. Hmmn. Since I never said that a vendor would have to classify all domains, and explicitly said that a code zero would mean don't know, I have to conclude that whatever you're opposed to is something other than the proposal I made a few messages back. So I don't see any further point in arguing here. R's, John From ietf-dkim@kitterman.com Thu Aug 12 08:09:10 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 697933A6835 for ; Thu, 12 Aug 2010 08:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.149 X-Spam-Level: X-Spam-Status: No, score=-4.149 tagged_above=-999 required=5 tests=[AWL=-1.550, 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 UMp6ER6q3OaK for ; Thu, 12 Aug 2010 08:09:09 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id 3E9263A6900 for ; Thu, 12 Aug 2010 08:09:09 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id BB5DD38C0BD; Thu, 12 Aug 2010 11:09:45 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1281625786; bh=B5/tt6IY3nlrj86i28FC9Vkk3FhG/+u+YUMfbI2kh74=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=HWS306hzg5pj28L95DreaO+ng7hFBUNbSOGNmALvbIECGc1KFFFioakpJLXJFChil 6622nflu29MzGxSmSK9XfY/0WV0fhvDgKdLsjmZvLhdMYpOlHQilZS1sezVsck1j6C wjJFsIX3t0gOwqcHUv63UrOPerYiVx4jrauI3aBw= From: Scott Kitterman To: domainrep@ietf.org Date: Thu, 12 Aug 2010 11:09:44 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <20100812011536.52399.qmail@joyce.lan> <4C63B14C.5060202@cs.tcd.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008121109.45090.ietf-dkim@kitterman.com> X-AV-Checked: ClamAV using ClamSMTP Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 15:09:10 -0000 On Thursday, August 12, 2010 10:39:46 am John R. Levine wrote: > > In any case, this is all extremely premature. I think you > > first need to say why an organisation classification value > > is generally useful before its encoding becomes an issue. > > Sigh. As I think I've said at least three times now, some mail systems > may want to handle incoming mail differently if they know it's from a > particular kind of organization, with banks and governments being the > usual examples. > > This isn't hypothetical. When we were talking about this at DAC, people > who handle rather a lot more mail than you or I do said this would be > useful. +1 This isn't just convenience either. My research with scalar reputation values convinces me this data point would affect how I do the math for what's "OK" or "not OK". Scott K From paul.hoffman@vpnc.org Thu Aug 12 08:10: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 91BBA3A6900 for ; Thu, 12 Aug 2010 08:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.087 X-Spam-Level: X-Spam-Status: No, score=-100.087 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553, 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 XyH-2GLUpVFD for ; Thu, 12 Aug 2010 08:10:23 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 3AE673A6937 for ; Thu, 12 Aug 2010 08:10:23 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o7CF9d0F011624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Aug 2010 08:09:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4C640A5F.6080008@cs.tcd.ie> References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C640A5F.6080008@cs.tcd.ie> Date: Thu, 12 Aug 2010 08:09:37 -0700 To: Stephen Farrell , "John R. Levine" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 15:10:24 -0000 At 3:51 PM +0100 8/12/10, Stephen Farrell wrote: >On 12/08/10 15:39, John R. Levine wrote: >>> In any case, this is all extremely premature. I think you >>> first need to say why an organisation classification value >>> is generally useful before its encoding becomes an issue. >> >> Sigh. As I think I've said at least three times now, some mail systems >> may want to handle incoming mail differently if they know it's from a >> particular kind of organization, with banks and governments being the >> usual examples. > >Yes, you have asserted that. But not said why its always or even >frequently relevant, i.e. what would I do with the information that >dance.example.com is probably an ok ballet company? Why does it need to even be "frequently" relevant? Many HTTP headers are rarely relevant, but we don't prohibit them or even suggest that they not be used. > > This isn't hypothetical. When we were talking about this at DAC, people >> who handle rather a lot more mail than you or I do said this would be >> useful. > >I don't doubt that. However, that doesn't mean that an industry >code of any sort is something that a generic Internet standard >for domain reputation should necessarily include as part of every >query response. Correct. Fortunately, that is not what John's proposal says. (We are talking about his specific proposal, yes?) >It could be that there are just a couple of interesting classes >of domain for which this is useful, and that the reputation >supplier might offer a different interface for querying those. >I don't know, but I'd hate to burden every client with having >to understand whatever classification system were to be used >and force every reputation vendor to classify all domains >accordingly. Fully agree. Fortunately, I didn't see that burden in the proposal. In fact, I would expect that most clients wouldn't understand *any* codes; they are only going to care about the rating. --Paul Hoffman, Director --VPN Consortium From stephen.farrell@cs.tcd.ie Thu Aug 12 08:23:54 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 C98643A698F for ; Thu, 12 Aug 2010 08:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=-0.800, 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 M8qgkcUXjxjW for ; Thu, 12 Aug 2010 08:23:53 -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 922F53A697A for ; Thu, 12 Aug 2010 08:23:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 3FAB13E408A; Thu, 12 Aug 2010 16:24:29 +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=1281626669; bh=/S0SX7m4bYsBc9 KEBNnC23YrtDiqPg9EBzQLwssCxMg=; b=uftjYv2zT4SpudMCNWjpX0P4f50wun 6vMYF4p8IUrzZY9Nl/soYkwS7gxoyXxb5nHNHzKqt6eWB5vjdU1FZyqGgWEp8qMC rG8eVMjkyprbiEkQBFVjFsyCjR/ewzkpJTq6fg0M0RTWt6xsNVRrCm2o6sAnIQ5c UEGZrnkFrXdu0jWXDKjdRAmpFUJF9pKYdc1cGW7ILy/AvRY3SaKByUDhL5B65L7l vsqu0YbL9TqJYaWZjhqgcdY8lVABoKkGQ2GCsvR0GeFDuHRnng1PrUfVpEv/cKw1 gp+b5oSnuMeUXQ1CZ8ErWHjVlv5aDXlni9VryahxicBWPyT6fBZBHtMQ== 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 yGPFsj+1EXPj; Thu, 12 Aug 2010 16:24:29 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 15EBB3E407D; Thu, 12 Aug 2010 16:24:28 +0100 (IST) Message-ID: <4C64122B.7090303@cs.tcd.ie> Date: Thu, 12 Aug 2010 16:24:27 +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: Paul Hoffman References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C640A5F.6080008@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "John R. Levine" , domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 15:23:54 -0000 On 12/08/10 16:09, Paul Hoffman wrote: >> I don't doubt that. However, that doesn't mean that an industry >> code of any sort is something that a generic Internet standard >> for domain reputation should necessarily include as part of every >> query response. > > Correct. Fortunately, that is not what John's proposal says. (We are talking about his specific proposal, yes?) Yes. I didn't see where that was optional to include. If I missed that, sorry. (And "Don't know" is different from missing I think.) >> It could be that there are just a couple of interesting classes >> of domain for which this is useful, and that the reputation >> supplier might offer a different interface for querying those. >> I don't know, but I'd hate to burden every client with having >> to understand whatever classification system were to be used >> and force every reputation vendor to classify all domains >> accordingly. > > Fully agree. Fortunately, I didn't see that burden in the proposal. In fact, I would expect that most clients wouldn't understand *any* codes; they are only going to care about the rating. If understanding the code is optional for clients, and unsupported by most, then why would it always be present? I can also imagine client implementers seeing this as an unnecessary burden unless its very very obviously optional. People will complain in cases where the response contains a code for something that the client doesn't grok even for those clients that do understand one or two codes. So make it part of some kind of extensibility thing maybe, then whatever the Italian equivalent for NAICS is could be used where its useful. Aside from that, I'm still not ok with the idea that we pretend that an industry code like NAICS is relevant for all domains, which is how I read his proposal. S. From msk@cloudmark.com Thu Aug 12 10:12:45 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 BBA823A6944 for ; Thu, 12 Aug 2010 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=-0.799, 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 f9xFZnkTS7Ew for ; Thu, 12 Aug 2010 10:12:44 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id C8D163A695B for ; Thu, 12 Aug 2010 10:12:44 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Aug 2010 10:13:21 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 12 Aug 2010 10:13:20 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs6MnflYsnkQyXbSoin/PIMlstBIwADrZHw Message-ID: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C640A5F.6080008@cs.tcd.ie> <4C64122B.7090303@cs.tcd.ie> In-Reply-To: <4C64122B.7090303@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 17:12:45 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Stephen Farrell > Sent: Thursday, August 12, 2010 8:24 AM > To: Paul Hoffman > Cc: John R. Levine; domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > Yes. I didn't see where that was optional to include. If I > missed that, sorry. (And "Don't know" is different from > missing I think.) > [...] > If understanding the code is optional for clients, and > unsupported by most, then why would it always be present? So is the solution here to make the two integers expressing reputation and = confidence mandatory, and the third (or any number of additional ones) opti= onal? For example: Reply =3D "r=3D" 1*DIGIT CFWS "c=3D" 1*DIGIT *( CFWS tag "=3D" 1*DIGIT ) ...where the other "tag"s get registered with their own semantics, or are d= efined by the reputation provider and out of scope for the protocol specifi= cation itself. Then if the provider wants to provide a "naics=3D" field, i= t can, and the clients can either use it or ignore it, and someone else can= provide its own encoding mechanism, etc. From msk@cloudmark.com Thu Aug 12 10: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 5B11F3A69A0 for ; Thu, 12 Aug 2010 10:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.389 X-Spam-Level: X-Spam-Status: No, score=-103.389 tagged_above=-999 required=5 tests=[AWL=-0.790, 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 PBXDuI5Sb2u8 for ; Thu, 12 Aug 2010 10:22:03 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 954FA3A690D for ; Thu, 12 Aug 2010 10:22:03 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Aug 2010 10:22:40 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 12 Aug 2010 10:22:40 -0700 Thread-Topic: [domainrep] Multi-Party [Web of Trust] XML Queries Thread-Index: Acs57fnDxMVVgRIVSKiADfnyRGvDNAAU8T9w Message-ID: References: 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] Multi-Party [Web of Trust] XML Queries 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, 12 Aug 2010 17:22:04 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Paul Ferguson > Sent: Thursday, August 12, 2010 12:14 AM > To: domainrep@ietf.org > Subject: [domainrep] Multi-Party [Web of Trust] XML Queries >=20 > So, I was contacted by several parties who expressed interest in my > earlier > mention of IODEF -- or something like it -- as a possible information > exchange mechanism. >=20 > I say "something like it" since it is simply nothing more than an > extensible XML query/response mechanism to exchange information. >=20 > It seems to me that, in contrast to trying to cram more stuff into DNS, > there is an alternative -- a "web" or multi-party XML query/response > entities. >=20 > This makes a lot of sense to me -- there is no need to define > limitations > in this scheme, since each entity determines on their own with whom > they > will query or respond. >=20 > In this scheme, the only work to be done is to determine how that data > would be encoded, any particular scalar ratings, etc. For the record, the arguments that have come up before against doing it thi= s way have included: - TCP is required for such a mechanism, and it's more heavyweight than UDP - you get DNS caching, redundancy, etc. for free if you do it that way - XML parsing is expensive compared to the amount of data you're encoding - you need to use the DNS anyway to find the place where this service is li= stening - nobody wants these complicated replies; the preference is just one or a f= ew scalars I don't know that I agree with any of these, but we should expect that any = text we produce will need to discuss these points. From msk@cloudmark.com Thu Aug 12 10:28:33 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 785693A69A9 for ; Thu, 12 Aug 2010 10:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.381 X-Spam-Level: X-Spam-Status: No, score=-103.381 tagged_above=-999 required=5 tests=[AWL=-0.782, 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 YQQkPu59TQ+B for ; Thu, 12 Aug 2010 10:28:32 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id AD1763A69A5 for ; Thu, 12 Aug 2010 10:28:32 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Aug 2010 10:29:09 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 12 Aug 2010 10:29:09 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs5+LvJGqQxS4j5SKe6niDRCMzBywASltew Message-ID: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> In-Reply-To: <4C63B14C.5060202@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 17:28:33 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Stephen Farrell > Sent: Thursday, August 12, 2010 1:31 AM > To: John R. Levine > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > People where? I think that were this an appropriate time to get > into that detail then the onus would be on you to show that this > could be acceptable outside of NA and that its coverage is > appropriate for the Internet and not just NA. I'm not sure I understand this objection, but maybe you touched on it below= : Is the fact that "NA" is in the name the objectionable part of this -- we= re I to take the entire data set and call it MFBC (Murray's Fun Business Co= des), would that make people feel better? -- or is there something about th= e way the data are actually organized that makes it the wrong approach? > I guess some folks might have an issue with change control > for the scheme residing with a national government, but that's > less of a concern for me. That was part of why I posed the "IANA" question earlier. At least then it= 's not governmental or perceived as US-centric, although it creates more wo= rk for IANA and sets a medium-height bar for adding to or otherwise amendin= g the list, plus implementers will need a way to stay abreast of changes. As for secret sauce leakage, maybe that's a good argument for making it opt= ional; if the algorithm treats all domains equally then exposure of differe= ntiating information might be seen as useful, while if the type of organiza= tion being reported is rolled into the reputation score itself, this become= s unnecessary. From dotis@mail-abuse.org Thu Aug 12 10:32: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 CA4D53A68EF for ; Thu, 12 Aug 2010 10:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.344 X-Spam-Level: X-Spam-Status: No, score=-106.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 1KpzBGGB+AFF for ; Thu, 12 Aug 2010 10:32:30 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id F18533A6979 for ; Thu, 12 Aug 2010 10:32: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 62E5CA947DB for ; Thu, 12 Aug 2010 17:33:01 +0000 (UTC) Message-ID: <4C64304D.2030804@mail-abuse.org> Date: Thu, 12 Aug 2010 10:33:01 -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: <20100810231119.71971.qmail@joyce.lan> <4C631989.1030203@att.com> <4C633E72.30002@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 17:32:30 -0000 On 8/11/10 7:14 PM, John R. Levine wrote: >> Put another way: why should the interesting part of the query >> have to include a domain name that exists in the DNS? > > Mostly to keep the scope of the project finite. (And, of course, it > does say "domainrep" up there on the subject line.) > > If people wanted to publish reputation for IP addresses, it'd be > obvious enough how to adapt the rDNS encoding to do that. I suppose > you could encode other stuff, but once you get past domains and IPs, > it appears to me that the utility rapidly drops off. John, If domain reputation is intended to support web reputation, as your breakdown suggests, then the path component also needs to be part of the query. Clearly such information should be encoded and not directly exchanged. For an example of how that might be done, see smart browsing. If domain reputation is intended to support email reputations, which appears to be the true intent, then there are other aspects that we have included in the past in our reputation services and appear to have become once again relevant. There are many ways third-party services can be offered. Some of these services do not: a) confirm the address of a subscriber b) authenticate the sender c) include Authentication-Results headers d) remove deceptive Authentication-Results headers e) include list-id header fields in their mailing-lists f) post process email for valid recipients Flags indicating the nature of a domain's traffic: 1) malware or phishing 2) bulk 3) transactional 4) financial 5) merchant 6) business 7) informational 8) amusement 9) advertisement 10) notification 11) phished 12) political 13) racial 14) sexual 15) gambling 16) language x, y, z 17) country x, y, z Decisions will be based upon general categories. A scheme that breaks business types into a fine granularity, will then need to be recombined back into general categories before a decision can be made. It seems illogical to impose the added burdens this would entail upon both the service provider and the consumer. -Doug From vesely@tana.it Thu Aug 12 11:00:55 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 02E9A3A69A0 for ; Thu, 12 Aug 2010 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-1.184, BAYES_50=0.001, DATE_IN_PAST_06_12=1.069, 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 UkhWa0V6ltTB for ; Thu, 12 Aug 2010 11:00:53 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 889E03A698C for ; Thu, 12 Aug 2010 11:00:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281636088; bh=4Xmdy49wThY29rJr71XW3nMEtrNfgDifFaQg/n68mW8=; l=2397; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=ZaEYLODFBfqt0EhLdIz08ZfB0Ly7DSwujIVf3PJbX0P73UkuNcstuCYJ4nMhPds9D z5YBqODRdcyQpYyL9oSYUc8SGhNNFf77VipfJLcnzwyuGsO/q/BadyBRwWbiS/qJkm I9q2zF1Dnm/mbjHy1nI5PeujmymJcbvxe4mF9Vok= Received: from [109.112.243.180] ([109.112.243.180]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 12 Aug 2010 20:01:27 +0200 id 00000000005DC037.000000004C6436F7.00000A52 Message-ID: <4C63CE8A.2010102@tana.it> Date: Thu, 12 Aug 2010 12:35:54 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> In-Reply-To: <4C61A49E.7080809@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] scope question - what apps? 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, 12 Aug 2010 18:00:55 -0000 Douglas Otis wrote: > On 8/10/10 10:24 AM, Paul Ferguson wrote: >> On Tue, Aug 10, 2010 at 9:19 AM, Douglas Otis wrote: >>> On 8/10/10 5:12 AM, Nathaniel Borenstein wrote: >>>> How, if at all, should a domain's reputation differ for different >>>> protocols? >>>> >>>> It seems to me that if a domain has been compromised or demonstrated to >>>> be antisocial in one context, it is highly likely to be equally >>>> untrustworthy in other contexts as well. Many services authenticate users based on their email addresses. For example, someone can open an account at gmail, use it to subscribe to a wiki web site, and then spam that wiki. I'm not sure whether Nathaniel means this kind of antisocial behavior. What should gmail do? >>> A domain would not be what is compromised, unless perhaps their DNS is. If email addresses are considered "domain citizenship", granting accounts anonymously, with no vetting whatsoever, should probably affect a domain's reputation. >> What about 100% malicious domains? > > When it comes to email and domains, email is significantly different from > other direct services. I think Doug is talking about typical mailbox providers. They can have "bad" users, compromised users, and abuse teams. Email marketers, MLMs, and other relays can also have users or customers on whose behalf the domain acts. This is where email is different. > Some domains are indeed being used extensively for illicit purposes. > But an illicit domain being used as desired by the domain owner has not > been compromised. As you suggest, these often deal with no legitimate > traffic. Right, and that traffic can be said to originate directly from the admins, not from the domain's users. > Another point that might be made is that reputation for such domains often > arrives too late. That point only makes sense for negative reputation. IMHO, the reputation of a domain is their ability in countering abuse. Is their abuse team efficient and effective? Perhaps, some domains would accept responsibility for what their users do, even for activities not directly related with the ability to send mail through the domain's MSA. It looks an intricate policy issue to me. At any rate, classifying domains according to how they grant new accounts may be an appealing task. From vesely@tana.it Thu Aug 12 11:01: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 D8C4C3A69CF for ; Thu, 12 Aug 2010 11:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.652 X-Spam-Level: X-Spam-Status: No, score=-3.652 tagged_above=-999 required=5 tests=[AWL=1.023, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 LHe0r0UIURgw for ; Thu, 12 Aug 2010 11:01:09 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id C500D3A69CE for ; Thu, 12 Aug 2010 11:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281636105; bh=vaWRT1B8npmRfAwxhHPJlQN316yNAtD152zH3JhhEHE=; l=458; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=JBoTlbXNDvoURjz4p/FuMVWMiUqzIQ294ciOI1rLrZWKXZh7mOG6HTThc7eUmMvGL Qxvu7hB+56gAm11cj+RAebGsl5BPcwPWtZpjSG8C10YVuSoAbvnKtcKsoPyW64oV7s 7G90QAnlANi7e2W8aqIpCRm8FKJfOIcfMiuc5u6s= Received: from [109.112.243.180] ([109.112.243.180]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 12 Aug 2010 20:01:44 +0200 id 00000000005DC037.000000004C643708.00000CB2 Message-ID: <4C63E876.8050801@tana.it> Date: Thu, 12 Aug 2010 14:26:30 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "domainrep@ietf.org" References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 18:01:09 -0000 Murray S. Kucherawy wrote: >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] >> >> Stop thinking about spam. Please. > > I didn't see anyone trying to constrain any of this activity specifically to email or anti-spam. Doug and I have been doing so. It's because email users can perpetrate abuse under a /domain/ name. Clients of other protocols can often be identified only by IP number --unless they logged in using an email address... From stpeter@stpeter.im Thu Aug 12 11:23: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 953823A69FF for ; Thu, 12 Aug 2010 11:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, 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 SI441w27vZys for ; Thu, 12 Aug 2010 11:23:38 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 25C7728C113 for ; Thu, 12 Aug 2010 11:23:38 -0700 (PDT) Received: from dhcp-64-101-72-121.cisco.com (dhcp-64-101-72-121.cisco.com [64.101.72.121]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id F10A840074 for ; Thu, 12 Aug 2010 12:25:27 -0600 (MDT) Message-ID: <4C643C4D.6080106@stpeter.im> Date: Thu, 12 Aug 2010 12:24:13 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: domainrep@ietf.org References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> <4C63CE8A.2010102@tana.it> In-Reply-To: <4C63CE8A.2010102@tana.it> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] scope question - what apps? 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, 12 Aug 2010 18:23:39 -0000 On 8/12/10 4:35 AM, Alessandro Vesely wrote: > Douglas Otis wrote: >> On 8/10/10 10:24 AM, Paul Ferguson wrote: >>> On Tue, Aug 10, 2010 at 9:19 AM, Douglas Otis >>> wrote: >>>> On 8/10/10 5:12 AM, Nathaniel Borenstein wrote: >>>>> How, if at all, should a domain's reputation differ for different >>>>> protocols? >>>>> >>>>> It seems to me that if a domain has been compromised or >>>>> demonstrated to >>>>> be antisocial in one context, it is highly likely to be equally >>>>> untrustworthy in other contexts as well. > > Many services authenticate users based on their email addresses. For > example, someone can open an account at gmail, use it to subscribe to a > wiki web site, and then spam that wiki. I'm not sure whether Nathaniel > means this kind of antisocial behavior. What should gmail do? > >>>> A domain would not be what is compromised, unless perhaps their DNS is. > > If email addresses are considered "domain citizenship", granting > accounts anonymously, with no vetting whatsoever, should probably affect > a domain's reputation. > >>> What about 100% malicious domains? >> >> When it comes to email and domains, email is significantly different from >> other direct services. > > I think Doug is talking about typical mailbox providers. They can have > "bad" users, compromised users, and abuse teams. Email marketers, MLMs, > and other relays can also have users or customers on whose behalf the > domain acts. This is where email is different. > >> Some domains are indeed being used extensively for illicit purposes. >> But an illicit domain being used as desired by the domain owner has >> not been compromised. As you suggest, these often deal with no >> legitimate traffic. > > Right, and that traffic can be said to originate directly from the > admins, not from the domain's users. > >> Another point that might be made is that reputation for such domains >> often >> arrives too late. > > That point only makes sense for negative reputation. > > IMHO, the reputation of a domain is their ability in countering abuse. > Is their abuse team efficient and effective? > > Perhaps, some domains would accept responsibility for what their users > do, even for activities not directly related with the ability to send > mail through the domain's MSA. It looks an intricate policy issue to > me. At any rate, classifying domains according to how they grant new > accounts may be an appealing task. For email services at a domain, yes. This is why I think the right level is the application service, such as email, IM, or VoIP, because the dimensions along which to measure a domain vary by application. For example, in the XMPP community we've sketched out some factors that make sense for us but probably don't make sense for email providers: http://xmpp.org/extensions/xep-0275.html Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Thu Aug 12 11:34:11 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 EDFD128C141 for ; Thu, 12 Aug 2010 11:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.373 X-Spam-Level: X-Spam-Status: No, score=-103.373 tagged_above=-999 required=5 tests=[AWL=-0.774, 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 kPZmDhnpdq83 for ; Thu, 12 Aug 2010 11:34:09 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id BC36B28C140 for ; Thu, 12 Aug 2010 11:34:09 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Aug 2010 11:34:46 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 12 Aug 2010 11:34:45 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs6SHTBc+8aB2cpT/eEaL4rpcX70wABGOug Message-ID: References: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> <4C63E876.8050801@tana.it> In-Reply-To: <4C63E876.8050801@tana.it> 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] A sketch of a small query reputation system 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, 12 Aug 2010 18:34:11 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Alessandro Vesely > Sent: Thursday, August 12, 2010 5:27 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > Murray S. Kucherawy wrote: > >> From: Paul Ferguson [mailto:fergdawgster@gmail.com] > >> > >> Stop thinking about spam. Please. > > > > I didn't see anyone trying to constrain any of this activity > specifically to email or anti-spam. >=20 > Doug and I have been doing so. It's because email users can perpetrate > abuse > under a /domain/ name. Clients of other protocols can often be > identified > only by IP number --unless they logged in using an email address... Well, then I disagree. There's certainly use in evaluating a domain name f= ound in a URL within an email, for example. A validated DKIM domain is but one of myriad possible questions that it wou= ld be useful to ask of a reputation system. I don't think we should try to= constrain this work in that way. From stephen.farrell@cs.tcd.ie Thu Aug 12 11:58:43 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 E4D9F3A685F for ; Thu, 12 Aug 2010 11:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.824 X-Spam-Level: X-Spam-Status: No, score=-102.824 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 B1tEodKdDUVC for ; Thu, 12 Aug 2010 11:58:42 -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 BCE053A6951 for ; Thu, 12 Aug 2010 11:58:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 929C23E408A; Thu, 12 Aug 2010 19:59:17 +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=1281639557; bh=GtsKlO0D4tyMcV tL/vhoMCbd38PaglQdl7r3Wnn/Hts=; b=jdvzofSA0aNRXmrGpxvKLZCUvoi+ey PNHDBkYiHU8P7T88Zpa441fIZSfptEiHw2in+XqllN/qMT/riAITrHvDiNIzXO7v eIRGGmajGKg/jZMdWFH+zNWsfHH9ZKziW+/RRhL0irerNDLjTfDW5nP/KJ2Z+hVN dlmwlhMyFVf0pEIpdev1bvbcO+6gazf8cKFPLemUk1BGjAr94pbP2a2VGxijA2KB e5YiVopUkrf1lPlPU9XTRd3NCXgWgl09+rjYfjhlnQgmDKBpX7a18JvsGfYujD1+ tDXjlpxGh1DpZNOU4e88qye15BI9NKtxAuAt+L14Qod1iYNM9XFSVvLQ== 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 Ce6Pb64CAQja; Thu, 12 Aug 2010 19:59:17 +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 23BE53E407D; Thu, 12 Aug 2010 19:59:16 +0100 (IST) Message-ID: <4C644481.8030405@cs.tcd.ie> Date: Thu, 12 Aug 2010 19:59:13 +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: "Murray S. Kucherawy" References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C640A5F.6080008@cs.tcd.ie> <4C64122B.7090303@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 18:58:44 -0000 On 12/08/10 18:13, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On >> Behalf Of Stephen Farrell >> Sent: Thursday, August 12, 2010 8:24 AM >> To: Paul Hoffman >> Cc: John R. Levine; domainrep@ietf.org >> Subject: Re: [domainrep] A sketch of a small query reputation system >> >> Yes. I didn't see where that was optional to include. If I >> missed that, sorry. (And "Don't know" is different from >> missing I think.) >> [...] >> If understanding the code is optional for clients, and >> unsupported by most, then why would it always be present? > > So is the solution here to make the two integers expressing reputation and confidence mandatory, and the third (or any number of additional ones) optional? For example: > > Reply = "r=" 1*DIGIT CFWS "c=" 1*DIGIT *( CFWS tag "=" 1*DIGIT ) > > ...where the other "tag"s get registered with their own semantics, or are defined by the reputation provider and out of scope for the protocol specification itself. Then if the provider wants to provide a "naics=" field, it can, and the clients can either use it or ignore it, and someone else can provide its own encoding mechanism, etc. Right, that'd work. I assume there'd be a need to be an IANA registry for "naics=" and its ilk. S. > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > From stephen.farrell@cs.tcd.ie Thu Aug 12 12:38: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 9EEB63A6A46 for ; Thu, 12 Aug 2010 12:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.807 X-Spam-Level: X-Spam-Status: No, score=-102.807 tagged_above=-999 required=5 tests=[AWL=-0.208, 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 GXoeAXUEIaVE for ; Thu, 12 Aug 2010 12:38:01 -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 7CB333A6A2E for ; Thu, 12 Aug 2010 12:37:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id B62683E408D; Thu, 12 Aug 2010 20:15:18 +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=1281640518; bh=L24ODq4llXW3Pz 31pvYLTnV6BRVuzh2pFTaQx1vYv6Q=; b=PWo/+FaPFWKjInESdz4AZInadDkH/r 2ed0teFgvkIOHqBdb8bCO7Al9Dw0UUWfuQTenfnFA3xQwG7UKI5dd78wPSv5+e92 IerL2YikencUDj9OZu/MY8cI2y/1aoCgwsdIca4K22iDarb7r2xt/InsTcuU8q6T +YKbHljHdSYsIG7Ljw7RFyUtGrzlwPGtKAVcFmBWt2kjKkeVENt3Xfko9Zx6SR7A T10NgprPRwyyuTidm9BA9MImDQhGXikkjmFUUlyP2kKxuN6JRUZwaXO9KNs/ZWNR FhQ09xjwrYd3Qi88r9l9n7Si6I0H0x2Tpw4nx7YGuBE7oP4ObTF6Smmg== 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 UmiYLeQvOede; Thu, 12 Aug 2010 20:15:18 +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 F18AB3E408A; Thu, 12 Aug 2010 20:15:17 +0100 (IST) Message-ID: <4C644844.3020700@cs.tcd.ie> Date: Thu, 12 Aug 2010 20:15:16 +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: "Murray S. Kucherawy" References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 19:38:02 -0000 On 12/08/10 18:29, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Thursday, August 12, 2010 1:31 AM >> To: John R. Levine >> Cc: domainrep@ietf.org >> Subject: Re: [domainrep] A sketch of a small query reputation system >> >> People where? I think that were this an appropriate time to get >> into that detail then the onus would be on you to show that this >> could be acceptable outside of NA and that its coverage is >> appropriate for the Internet and not just NA. > > I'm not sure I understand this objection, but maybe you touched on it below: Is the fact that "NA" is in the name the objectionable part of this -- were I to take the entire data set and call it MFBC (Murray's Fun Business Codes), would that make people feel better? -- or is there something about the way the data are actually organized that makes it the wrong approach? No. I'd have the same problem with an Irish industry code. I'm apparently not getting this over, so I'll give it one more try. (But with an optional code, its much less of an issue, so no need to keep this going.) I have at least three problems with the NAICS suggestion: - Its a regional classification designed for other (statistical) purposes. I very much doubt that any such regional classification will map to the entire Internet. For example, I wouldn't be surprised if an EU financial regulator objected to some US reputation vendor assigning an EU regional code that means that a domain is part of a financial institution, I'm willing to bet a beer that some such problem would arise somewhere. - 2nd problem is also regional-related: one cannot expect client implementers and reputation service providers from outside whatever region produced the scheme to apply it correctly or easily. The NAICS site says that you can pay someone to give you lists of the NAICS codes for businesses. I very much doubt any of the companies who sell that are solely based in New Zealand and I suspect that any NZ reputation supplier would be disadvantaged by that and more likely to err. The same issue would arise with any regional code that aimed to cover the entire Internet. - Its an industrial code. Not all domains are related to industry, and so therefore cannot be classified, so its clearly unsuitable on that basis alone, except for a subset of domains. Anyway, as an optional thing, its just fine if folks want to do that, so long as we all aren't expected to do it. S. > >> I guess some folks might have an issue with change control >> for the scheme residing with a national government, but that's >> less of a concern for me. > > That was part of why I posed the "IANA" question earlier. At least then it's not governmental or perceived as US-centric, although it creates more work for IANA and sets a medium-height bar for adding to or otherwise amending the list, plus implementers will need a way to stay abreast of changes. > > As for secret sauce leakage, maybe that's a good argument for making it optional; if the algorithm treats all domains equally then exposure of differentiating information might be seen as useful, while if the type of organization being reported is rolled into the reputation score itself, this becomes unnecessary. > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > From msk@cloudmark.com Thu Aug 12 13:23:22 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 C31853A69A9 for ; Thu, 12 Aug 2010 13:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.365 X-Spam-Level: X-Spam-Status: No, score=-103.365 tagged_above=-999 required=5 tests=[AWL=-0.766, 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 CrrUjkFu0iBA for ; Thu, 12 Aug 2010 13:23:22 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 0648F3A6909 for ; Thu, 12 Aug 2010 13:23:22 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 12 Aug 2010 13:23:59 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 12 Aug 2010 13:23:58 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs6UragWheuUhohS+eRnCeFZyjXwgACSYpw Message-ID: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C644844.3020700@cs.tcd.ie> In-Reply-To: <4C644844.3020700@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 20:23:22 -0000 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Thursday, August 12, 2010 12:15 PM > To: Murray S. Kucherawy > Cc: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > I have at least three problems with the NAICS suggestion: >=20 > - Its a regional classification designed for other (statistical) > purposes. I very much doubt that any such regional > classification will map to the entire Internet. For example, > I wouldn't be surprised if an EU financial regulator objected > to some US reputation vendor assigning an EU regional code > that means that a domain is part of a financial institution, > I'm willing to bet a beer that some such problem would > arise somewhere. I guess the use of "regional" in this debate is what baffles me. That inte= ger X means "bank" doesn't seem to me to have a regional component, other t= han who assigned it. If that's not the issue, I guess then the concern is = that what qualifies as "bank" in one region might be different than in anot= her. Is that it? From ajs@shinkuro.com Thu Aug 12 13:27:19 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 5AC8B3A6827 for ; Thu, 12 Aug 2010 13:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.538 X-Spam-Level: X-Spam-Status: No, score=-101.538 tagged_above=-999 required=5 tests=[AWL=1.061, 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 xyM9OVVPXSNu for ; Thu, 12 Aug 2010 13:27:18 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7FF363A6909 for ; Thu, 12 Aug 2010 13:27:18 -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 81A3B1ECB41D for ; Thu, 12 Aug 2010 20:27:55 +0000 (UTC) Date: Thu, 12 Aug 2010 16:27:53 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100812202753.GJ64251@shinkuro.com> References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C644844.3020700@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 20:27:19 -0000 On Thu, Aug 12, 2010 at 01:23:58PM -0700, Murray S. Kucherawy wrote: > I guess then the concern is that what qualifies as "bank" in one > region might be different than in another. Is that it? It would seem that an early question any taxonomy is going to run into is, "Who decides?" A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From msk@cloudmark.com Thu Aug 12 13:30:54 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 704D03A69B0 for ; Thu, 12 Aug 2010 13:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.358 X-Spam-Level: X-Spam-Status: No, score=-103.358 tagged_above=-999 required=5 tests=[AWL=-0.759, 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 UUNGOXF2P+ph for ; Thu, 12 Aug 2010 13:30:52 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id E01103A6962 for ; Thu, 12 Aug 2010 13:30:52 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 12 Aug 2010 13:31:30 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 12 Aug 2010 13:31:29 -0700 Thread-Topic: [domainrep] A sketch of a small query reputation system Thread-Index: Acs6XNo5RxmFPAfYRKq3O1zPNuo9xwAADqaw Message-ID: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C644844.3020700@cs.tcd.ie> <20100812202753.GJ64251@shinkuro.com> In-Reply-To: <20100812202753.GJ64251@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] A sketch of a small query reputation system 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, 12 Aug 2010 20:30:54 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Thursday, August 12, 2010 1:28 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] A sketch of a small query reputation system >=20 > On Thu, Aug 12, 2010 at 01:23:58PM -0700, Murray S. Kucherawy wrote: >=20 > > I guess then the concern is that what qualifies as "bank" in one > > region might be different than in another. Is that it? >=20 > It would seem that an early question any taxonomy is going to run > into is, "Who decides?" For that matter, why does everyone think ASCII is okay? Isn't the "A" part= objectionable? I'd be perfectly fine with any table matching integers to business types, n= o matter who comes up with it. I guess that's why I don't get the objectio= n. There must be something about that particular data set that I just don'= t get yet. From stephen.farrell@cs.tcd.ie Thu Aug 12 13:53:57 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 0DFFF3A6995 for ; Thu, 12 Aug 2010 13:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.792 X-Spam-Level: X-Spam-Status: No, score=-102.792 tagged_above=-999 required=5 tests=[AWL=-0.193, 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 EQzIyv9ajQET for ; Thu, 12 Aug 2010 13:53:56 -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 E3C693A6940 for ; Thu, 12 Aug 2010 13:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E35793E4090; Thu, 12 Aug 2010 21:54:30 +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=1281646470; bh=/lk7qzA3Ox4oIt LphTPvue78S43c5Sl//NlR+vqUoM8=; b=aJZjkDDqQPCtdopF+fKDu9cFwM8Qqz oW4zeRuXcpQaMC/dlLNB9L844gwRmxLkFzcY7qwckcKAt6VL6IoGnpSm3OS11hG5 jZDmBHw0HvVxxry1kq5OSxY/L9ssp+4Xst7m9B5gIWvVF7Yc6bJvp/ootB7pNSyB ZxVtm4td5zWU4ftBy865MNN8DUnlgwk5iab3gu2HEIf6KehAOn4ADhbAJZPLwsAz zgwuZB5edwfRvLEtljTqiHeAn1T/qEg/GmlCwErK86J4+BTHdK0HFKUhOpMwgmgG 8j8LuQGeM+3BwibX0sevYurzvye6lDargtq+T647bYPpOGyTtcdbnOxA== 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 SarYYBPx9E9P; Thu, 12 Aug 2010 21:54:30 +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 9644D3E408D; Thu, 12 Aug 2010 21:54:30 +0100 (IST) Message-ID: <4C645F84.7080205@cs.tcd.ie> Date: Thu, 12 Aug 2010 21:54:28 +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: "Murray S. Kucherawy" References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C644844.3020700@cs.tcd.ie> 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] A sketch of a small query reputation system 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, 12 Aug 2010 20:53:57 -0000 On 12/08/10 21:23, Murray S. Kucherawy wrote: > I guess the use of "regional" in this debate is what baffles me. That integer X means "bank" doesn't seem to me to have a regional component, other than who assigned it. If that's not the issue, I guess then the concern is that what qualifies as "bank" in one region might be different than in another. Is that it? Right, that's an example. There are literally 10's of thousands of Swiss savings banks (or were, when I did a bit of work related to that a decade ago), some with only one or two employees, then there are microfinance outfits in developing regions, credit unions, some of which are for particular city districts, and some that are part of larger industrial enterprises with nothing to do with banking (in Ireland), there's the Swedish farmer's union that has (or had) its own a bank, etc etc. so even in one of the most regulated areas things vary a lot once you get outside a particular region. Are you telling me that NAICS has relevant codes for all of those? How would you know? Or try football, that's three totally different sports in the US, UK and Ireland:-) How about medical? I've no idea how that might work in China for example (and hope not to find out when we go there:-) Point is, if all you care about is if the reputation service says its a bank then there's no need to inherit any of that complexity. If there are only a small set of domain types that might be useful then just start an IANA registry. (However, before using that value, a reputation provider might want to check with their local financial regulator if they're allowed make such statements, I dunno.) But once more: I'm ok as long as its really optional. S. From dotis@mail-abuse.org Thu Aug 12 14:31: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 B260A3A67F0 for ; Thu, 12 Aug 2010 14:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 moujoL9Uu1fB for ; Thu, 12 Aug 2010 14:31: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 5EFCD3A67B3 for ; Thu, 12 Aug 2010 14:31:23 -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 024ECA9449A for ; Thu, 12 Aug 2010 21:31:54 +0000 (UTC) Message-ID: <4C646849.4030505@mail-abuse.org> Date: Thu, 12 Aug 2010 14:31:53 -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: <20100810231119.71971.qmail@joyce.lan> <4C61EA85.5080707@cs.tcd.ie> <201008102017.34211.ietf-dkim@kitterman.com> <4C61F823.8090207@mail-abuse.org> <4C63E876.8050801@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 21:31:24 -0000 On 8/12/10 11:34 AM, Murray S. Kucherawy wrote: > > On Thursday, August 12, 2010 5:27 AM Alessandro Vesely wrote: > > Murray S. Kucherawy wrote: > >>> From: Paul Ferguson [mailto:fergdawgster@gmail.com] Stop > >>> thinking about spam. Please. > >> I didn't see anyone trying to constrain any of this activity > > specifically to email or anti-spam. > > > > Doug and I have been doing so. It's because email users can > > perpetrate abuse under a /domain/ name. Clients of other protocols > > can often be identified only by IP number --unless they logged in > > using an email address... > > Well, then I disagree. There's certainly use in evaluating a domain > name found in a URL within an email, for example. In order to evaluate a URI found within an email, more than just the domain MUST be included. Often shortened URLs require the path to evaluate the actual source. > A validated DKIM domain is but one of myriad possible questions that > it would be useful to ask of a reputation system. I don't think we > should try to constrain this work in that way. Unless such a system is allowed to cover more than just a domain, the utility of the service is significantly limited to perhaps: a) the complete blocking of a malicious domain b) authenticated domains of email addresses c) authenticated domains of host names Due to the fact that email does not require any domain to have been authenticated, some will want to base reputation on domains authorizing the actions of a host by its IP address. An authorization by IP address model for domain reputation would be extremely difficult to support, since there would not be any direct evidence of a domain having originated objectionable content. Without a way to determine whether an assumption is in error, errors might result in a domain being blocked without recourse. It is common to find providers authorized by thousands of domains. However, many providers do not correlate message elements that could be used as authorization with that of a particular sender. In addition, authorization might be based upon the return-path or upon the purported responsible address, where the intended address might not have been examined. Often authorization proponents disregard the lack of authentication, and insist that domains injured by any error must find different providers. Unfortunately, using a different provider will not resolve the problem created by erroneous reputations assigned to their domain. Its like a neighborhood park asking parents to authorize unaccompanied children they wish allowed in the facility. Guards at the park don't confirm the child's name, but accept the name given whenever it matches an authorization. Now imagine the park has decided to hold parents liable for actions of their authorized child, without anyone really knowing whether the child gave their true name when being admitted. To reliably accept email from sources within IPv6, a cryptographic method confirming the issuing host would be beneficial, since these IP addresses will prove problematic for establishing a source identity. If such a requirement for authenticating the issuing host was established for email, this would better ensure domains are not injured through incorrect source assumptions when establishing domain reputation. -Doug From johnl@iecc.com Thu Aug 12 14:40:53 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 D5A003A694E for ; Thu, 12 Aug 2010 14:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.615 X-Spam-Level: X-Spam-Status: No, score=-108.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_50=0.001, 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 UoAE2o-W0FQO for ; Thu, 12 Aug 2010 14:40:53 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id A35723A67E3 for ; Thu, 12 Aug 2010 14:40:52 -0700 (PDT) Received: (qmail 86216 invoked from network); 12 Aug 2010 21:41:29 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 12 Aug 2010 21:41:29 -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=k1008; olt=johnl@user.iecc.com; bh=iUsaiIR3DikUB170ReQQuKSmlrKHuG30CKPmrugzxII=; b=1CVF/RHtqRePEXr+3mNks84f7gnkB/txU+PwmrvyehrDHjzDuqgCoE4Xwa3zDjoVpI1rBsEoBjNKDLHeqJYgeVDpiFVFxlxZ/u4WsIZQboT1oMgVGiahIN3Cz88aes3VHSi84xcfsqPjBsyT/mJXSOc8lKfq2jRX78oIKM7JxWY= Date: 12 Aug 2010 21:41:28 -0000 Message-ID: <20100812214128.50562.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <4C645F84.7080205@cs.tcd.ie> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 21:40:53 -0000 >Right, that's an example. There are literally 10's of thousands of >Swiss savings banks (or were, when I did a bit of work related to >that a decade ago), some with only one or two employees, then there >are microfinance outfits in developing regions, credit unions, some >of which are for particular city districts, and some that are part of >larger industrial enterprises with nothing to do with banking (in >Ireland), there's the Swedish farmer's union that has (or had) its >own a bank, etc etc. so even in one of the most regulated areas >things vary a lot once you get outside a particular region. Are you >telling me that NAICS has relevant codes for all of those? How would >you know? Yeah. They're banks. Code 5221. What sort of maniac would waste time trying to invent separate reputation categories for all of them? We also have rather a lot of types of banks here in North America*, and NAICS does not have a hundred separate subcategories because there's no point. R's, John * - Utah industrial banks, and the Alberta Treasury Branches, for example From dotis@mail-abuse.org Thu Aug 12 15:35:51 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 04D603A6A13 for ; Thu, 12 Aug 2010 15:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.054 X-Spam-Level: X-Spam-Status: No, score=-105.054 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_50=0.001, 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 96fVCAyAQfDg for ; Thu, 12 Aug 2010 15:35:45 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id CAB7C3A6987 for ; Thu, 12 Aug 2010 15:35:45 -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 1F5E6A947DC for ; Thu, 12 Aug 2010 22:36:17 +0000 (UTC) Message-ID: <4C647760.5030300@mail-abuse.org> Date: Thu, 12 Aug 2010 15:36:16 -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: <20100812214128.50562.qmail@joyce.lan> In-Reply-To: <20100812214128.50562.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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, 12 Aug 2010 22:35:51 -0000 On 8/12/10 2:41 PM, John Levine wrote: >> Right, that's an example. There are literally 10's of thousands of >> Swiss savings banks (or were, when I did a bit of work related to >> that a decade ago), some with only one or two employees, then there >> are microfinance outfits in developing regions, credit unions, some >> of which are for particular city districts, and some that are part of >> larger industrial enterprises with nothing to do with banking (in >> Ireland), there's the Swedish farmer's union that has (or had) its >> own a bank, etc etc. so even in one of the most regulated areas >> things vary a lot once you get outside a particular region. Are you >> telling me that NAICS has relevant codes for all of those? How would >> you know? > Yeah. They're banks. Code 5221. What sort of maniac would waste > time trying to invent separate reputation categories for all of them? > > We also have rather a lot of types of banks here in North America*, > and NAICS does not have a hundred separate subcategories because > there's no point. NAICS has 19746 items combined into different categories. I can imagine having a category representing "public safety" which then might include NOAA, and its equivalent for different regions, and things like fire, ambulance, police, but these are spread out into different categories. This list also includes 812990 balloon-o-gram services, and 16342 Facsimile machine rental or leasing, but nothing directly for an email provider, and its many subcategories. Internally we have our own set of categories that are flagged as bits within a large large integer. Categorization should relate to the protocol evaluated. NAICS appears to represent a fairly poor fit for most Internet related protocols. Many of these categories seem related to different tax revenue sources based on fairly old regulations. -Doug From vesely@tana.it Fri Aug 13 03:35:26 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 8DC1C3A69B8 for ; Fri, 13 Aug 2010 03:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.096 X-Spam-Level: X-Spam-Status: No, score=-3.096 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 jJxdM84zZI8q for ; Fri, 13 Aug 2010 03:35:25 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 158E83A69B4 for ; Fri, 13 Aug 2010 03:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281695757; bh=WHPXvuIOvWYn1CZHKG/Dmw9iy6LjeLWIUCbfsV8NHz4=; l=1777; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=RE2vF5MkMxcSAW0tEi/10ac81uFYdpFpYkO3skw+OQVpyDMTKAFK/09SVtG/RDE4P tUN5LjfShbLc5AZjOj3R0SE/Q5y63zrWNNHgxBjuKcfLlAQZ3B52XZByxP8K69DH3/ p7zxM4lnerhIcrpi7FR965iUMq0CgJmRpry2k63M= Received: from [172.25.197.80] (minivista.tana [172.25.197.80]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 13 Aug 2010 12:35:57 +0200 id 00000000005DC03C.000000004C65200D.00007E23 Message-ID: <4C652007.4070000@tana.it> Date: Fri, 13 Aug 2010 12:35:51 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> <4C63CE8A.2010102@tana.it> <4C643C4D.6080106@stpeter.im> In-Reply-To: <4C643C4D.6080106@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] scope question - what apps? 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: Fri, 13 Aug 2010 10:35:26 -0000 Peter Saint-Andre wrote: > On 8/12/10 4:35 AM, Alessandro Vesely wrote: >> Many services authenticate users based on their email addresses. >> [...] >> Perhaps, some domains would accept responsibility for what their users >> do, even for activities not directly related with the ability to send >> mail through the domain's MSA. It looks an intricate policy issue to >> me. At any rate, classifying domains according to how they grant new >> accounts may be an appealing task. > > For email services at a domain, yes. This is why I think the right level > is the application service, such as email, IM, or VoIP, because the > dimensions along which to measure a domain vary by application. Along that line, for HTTP, admin-edited content may be considered differently than users' blogs. There is a positive range when reputation measures a domain's ability at controlling their users. > For example, in the XMPP community we've sketched out some factors that > make sense for us but probably don't make sense for email providers: > > http://xmpp.org/extensions/xep-0275.html What is named "Server Reputation" in that document, may well be called "Domain Reputation" in this list's context. I think that sketch is a good example of how reputation can be measured. Of course, some criteria are application specific. The score is set up so as to suggest that scores in, say, domain._chat._rep.scorekeeper.example are added (or have to be added by the client) to the generic domain._rep.scorekeeper.example. As a minor point, I'd prefer logarithmic scales. For example, there is no substantial difference between seven and six years of online service, while the difference between one and zero is very relevant. From vesely@tana.it Fri Aug 13 03:46:36 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 C744D3A67AF for ; Fri, 13 Aug 2010 03:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.708 X-Spam-Level: X-Spam-Status: No, score=-3.708 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_51=0.6, 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 e9UiTy36EzCl for ; Fri, 13 Aug 2010 03:46:35 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 58F103A693F for ; Fri, 13 Aug 2010 03:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281696431; bh=Hel/ab2sFXqM+l49zAbQpCkoGxmbXZty+ZB/JIiksn8=; l=1063; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=iRfeM0vLeMu+1ktSbNJWGqv96/DCkoy98mspoIqb1hfSo08JMAEFA8L/6mrQ9v2Ks LbXKa2LNXRZ7BmWHOoNFav/21/1jpxoOaZkNAhjzGDQfNO2blMDD9W4jkJ85IfYKEi ED9+sYugGMUvaspENC7H5JB+Xi/YCgfsMD3EdsFI= Received: from [172.25.197.80] (minivista.tana [172.25.197.80]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 13 Aug 2010 12:47:11 +0200 id 00000000005DC037.000000004C6522AF.00003339 Message-ID: <4C6522AE.4020502@tana.it> Date: Fri, 13 Aug 2010 12:47:10 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <20100811050530.57875.qmail@joyce.lan> In-Reply-To: <20100811050530.57875.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 10:46:36 -0000 John Levine wrote: > For anyone who cares about this, here's the NAICS web site, where you > can look at all the categories: > > http://www.census.gov/eos/www/naics/ > > The UN has something called ISIC, but it seems to be much less widely > used, and looks awfully clunky. Class 6190 includes dialup ISPs, > satellite base stations, and telecom resellers. But central banks > have their own class 6411. > > http://unstats.un.org/unsd/cr/registry/isic-4.asp FWIW, there is an European classification http://epp.eurostat.ec.europa.eu/portal/page/portal/nace_rev2/introduction Possibly, the right syntax is "code=X, code-type=NAICS", rather than naics=X. IMHO, such info should be provided by the registrar in the relevant WHOIS field. Is caching/complementing WHOIS an integral part of a domain reputation system? Rather than (or in addition to) detailed industrial classification, I think it is relevant to answer Internet-specific questions, such as who are the domain's users, how they subscribe, and the like. From vesely@tana.it Fri Aug 13 04:02:12 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 E9F543A6994 for ; Fri, 13 Aug 2010 04:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.037 X-Spam-Level: X-Spam-Status: No, score=-4.037 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, 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 ZPPq7sba5k8h for ; Fri, 13 Aug 2010 04:02:11 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 904903A693F for ; Fri, 13 Aug 2010 04:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281697367; bh=KGaQbiQnU4L+9MfIyBwxv7sdRNoBClRSMH2xJ0/12Vg=; l=909; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=EN+mpkdGYJbNBPVXPsyZ7o2Hjg/GtYO1Dw5fMOVlEhDAySEuXqMu34z5FkWLb8xxB q+DjrZL2ALQwyj4pK2juDa5tl1hvxhHHgqvwyh0NyyGJxdDMBVIKtlo3/Gzeb2mUrg mySL4SX4I4NYzBTQOy2/tW/PYQ6hlBOgSvBViAQI= Received: from [172.25.197.80] (minivista.tana [172.25.197.80]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 13 Aug 2010 13:02:47 +0200 id 00000000005DC036.000000004C652657.00007947 Message-ID: <4C652656.5070309@tana.it> Date: Fri, 13 Aug 2010 13:02:46 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Multi-Party [Web of Trust] XML Queries 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: Fri, 13 Aug 2010 11:02:13 -0000 Paul Ferguson wrote: > So, I was contacted by several parties who expressed interest in my earlier > mention of IODEF -- or something like it -- as a possible information > exchange mechanism. Rather than the format, IODEF is relevant because incident handling is a good input for reckoning reputation. Besides IODEF, which is oriented toward connection providers, MARF provides for a similar context in email. As for the "Multi-Party", every admin that had an occasion to interact with a given domain's abuse team, is a "party" who provides part of the score. When I, as an enquirer, retrieve the score of that domain, I'd obviously be more interested in the evaluations given by admins of domains I trust. I propose no formula yet, but tend to consider the trust as a multiplicative factor, so that contributions to reputation scores are weighted according to the web of trust. From nsb@guppylake.com Fri Aug 13 04:13: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 653A83A6765 for ; Fri, 13 Aug 2010 04:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 TnO2CEXXNnXl for ; Fri, 13 Aug 2010 04:13:31 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 6860B3A6358 for ; Fri, 13 Aug 2010 04:13:31 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OjsPR-00033n-Rd; Fri, 13 Aug 2010 07:26:50 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4C63CE8A.2010102@tana.it> Date: Fri, 13 Aug 2010 07:14:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <09DBFDD5-BB31-43A0-9D6C-AF7CA535CD35@guppylake.com> References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> <4C63CE8A.2010102@tana.it> To: Alessandro Vesely 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] scope question - what apps? 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: Fri, 13 Aug 2010 11:13:32 -0000 On Aug 12, 2010, at 6:35 AM, Alessandro Vesely wrote: > Many services authenticate users based on their email addresses. For = example, someone can open an account at gmail, use it to subscribe to a = wiki web site, and then spam that wiki. I'm not sure whether Nathaniel = means this kind of antisocial behavior. What should gmail do? It's not what I was thinking of, but it's another good example. I just = doubt that, over the long term, we'll be able to maintain the notion of = different reputations in different contexts for a single domain/IP = address/email address. If you knew that something had a bad reputation = in one context, and no reputation in another context, mightn't the = former reputation be better than nothing in the latter context? On the other hand, the bad guys might use a combined reputation system = to do good things in one context to offset the negative reputation from = the context in which they are making mischief. =20 Perhaps instead of talking about reputations for each service, we should = think about generic reputations with details about the kinds of negative = information they're based on? As in "Reputation =3D 3.1/100; = abuse-types: phishing=3D7,spam=3D325,double-parking=3D1" (Oh, goody, = another registry.) We might also worry about representing the recency = of the bad events, too. This is complex stuff, and I'm not sure we can = (or should) reduce it to a really simple score. -- Nathaniel From nsb@guppylake.com Fri Aug 13 04:21:08 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 63E653A6765 for ; Fri, 13 Aug 2010 04:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 uPWtHWMEpv4D for ; Fri, 13 Aug 2010 04:21:07 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id CCDA23A6783 for ; Fri, 13 Aug 2010 04:21:06 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OjsWn-00044J-UA; Fri, 13 Aug 2010 07:34:26 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4C647760.5030300@mail-abuse.org> Date: Fri, 13 Aug 2010 07:21:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36C6717E-C119-47CE-9303-D0170FE1011F@guppylake.com> References: <20100812214128.50562.qmail@joyce.lan> <4C647760.5030300@mail-abuse.org> To: Douglas Otis 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] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 11:21:08 -0000 On Aug 12, 2010, at 6:36 PM, Douglas Otis wrote: > NAICS has 19746 items combined into different categories I worry more about the 19746 than the NA. How many of these categories are there? I think we need a human-scale = number (1 or 2 digits) if we're going to be able to develop software = that can discriminate meaningful based on such distinctions among = institutions. A small number of categories = (financial/medical/retail/educational/etc., or = text/image/video/audio/message/multipart/application) is often more = manageable than a large one. I think it should be as small as possible = (but no smaller). -- nsb= From dotis@mail-abuse.org Fri Aug 13 10:19:26 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 49EEE3A6969 for ; Fri, 13 Aug 2010 10:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.405 X-Spam-Level: X-Spam-Status: No, score=-105.405 tagged_above=-999 required=5 tests=[AWL=-0.665, BAYES_20=-0.74, 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 1hPKHdphr8P8 for ; Fri, 13 Aug 2010 10:19:25 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 7B8AD3A68F1 for ; Fri, 13 Aug 2010 10:19:25 -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 EF615A94763; Fri, 13 Aug 2010 17:19:58 +0000 (UTC) Message-ID: <4C657EBE.7060202@mail-abuse.org> Date: Fri, 13 Aug 2010 10:19:58 -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: Nathaniel Borenstein References: <20100812214128.50562.qmail@joyce.lan> <4C647760.5030300@mail-abuse.org> <36C6717E-C119-47CE-9303-D0170FE1011F@guppylake.com> In-Reply-To: <36C6717E-C119-47CE-9303-D0170FE1011F@guppylake.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 17:19:26 -0000 On 8/13/10 4:21 AM, Nathaniel Borenstein wrote: > On Aug 12, 2010, at 6:36 PM, Douglas Otis wrote: >> NAICS has 19746 items combined into different categories > I worry more about the 19746 than the NA. > > How many of these categories are there? I think we need a human-scale number (1 or 2 digits) if we're going to be able to develop software that can discriminate meaningful based on such distinctions among institutions. A small number of categories (financial/medical/retail/educational/etc., or text/image/video/audio/message/multipart/application) is often more manageable than a large one. I think it should be as small as possible (but no smaller). -- nsb Might I also suggest the nature of traffic from a domain could fit into several categories. The way we handle this situation is to set bits within integers to flag each applicable category. In this way, a small response is able to contain a significant amount of actionable data. One then wonders how this might evolve. What about content not suitable for minors? Would such a category place a duty on the service to indicate such possible status? I agree with a small set of categories, which is what we use internally. Keeping it even simpler, such as sticking to categories declared in the IODEF format for example, could keep reporting from becoming a nanny service, which is something we also offer, but I doubt the IETF would endorse such... ugliness. When reputation is about email, it would be helpful to know whether they also offer third-party services that damage DKIM signatures. If they properly implement Authentication-Results headers. Whether the system publicly issuing their messages can be authenticated, and by using which method... etc. -Doug From johnl@iecc.com Fri Aug 13 10:21: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 AD61F3A6864 for ; Fri, 13 Aug 2010 10:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.614 X-Spam-Level: X-Spam-Status: No, score=-108.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_50=0.001, 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 uyy2UWn9cGhM for ; Fri, 13 Aug 2010 10:21:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 08B653A6802 for ; Fri, 13 Aug 2010 10:21:35 -0700 (PDT) Received: (qmail 77743 invoked from network); 13 Aug 2010 17:22:12 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 Aug 2010 17:22:12 -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=k1008; olt=johnl@user.iecc.com; bh=iDSBuhJ7vSq9hDGfOW5LY0E74l422QJz6b5M1QwLcTM=; b=bpeHV/jDV2OViIbZgFDSNowwW4hYfyslZzpEPN7RuvO7dlu4Z9WaR946yBC1atYKpKTHhCBpIGn0+KhxAX0DE4bp66ZxcSoFb4aAmFIKXhkt58alWHLang5+9GMZc74Wioumz5stcmG7TsE7SzQ9YmUIBr/2Fbcky+MgEwm7lhg= Date: 13 Aug 2010 17:22:12 -0000 Message-ID: <20100813172212.80598.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <36C6717E-C119-47CE-9303-D0170FE1011F@guppylake.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 17:21:41 -0000 >> NAICS has 19746 items combined into different categories ... >I think it should be as small as possible (but no smaller). -- nsb As I think I said in an earlier message, NAICS codes are like Dewey Decimal numbers, more digits give you finer distinctions. If you look here: http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2007 You'll see that there are about 25 two-digit areas, which are then broken down into finer areas. So, for example, 52 is Finance and Insurance, 522 is Credit Intermediaries and Related Activities, 5221 is Banks, 5222 is non-bank lenders, and 5223 is Activities Related to Credit Intermediation such as mortgage brokers. My expectation is that reputation services would publish as many digits as they know, and consumers would use as many digits as they find useful. So if you're treating all bank-like things the same, anything that starts with 522 is a bank. On the other hand, if you find mortgage brokers to be sleazier than banks, you might do something different with 5223. The UN's ISIC, and EU's NACE, which appears to be a mutant version of ISIC, work roughly the same way: 01 is farming, 01.4 is animal farming, 01.44 is camels and llamas, and 01.46 is swine. R's, John From johnl@iecc.com Fri Aug 13 11:05:37 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 1619D3A6805 for ; Fri, 13 Aug 2010 11:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.614 X-Spam-Level: X-Spam-Status: No, score=-109.614 tagged_above=-999 required=5 tests=[AWL=0.985, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, J_CHICKENPOX_51=0.6, 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 5dh9j2sbUIa4 for ; Fri, 13 Aug 2010 11:05:36 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id A7C983A6884 for ; Fri, 13 Aug 2010 11:05:35 -0700 (PDT) Received: (qmail 98984 invoked from network); 13 Aug 2010 18:06:12 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 13 Aug 2010 18:06:12 -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=k1008; olt=johnl@user.iecc.com; bh=wFt7SWG2qx9yNUs940u3y4LJx2DP/m9szQodpnYHyM8=; b=m2aXUVV8snqKe5uMzYStsleQ16dEQf09BgaEtzP7PEk1Ut0Kaakj1GARQvBXH4QDkmpBAfDFnINrK3HzciE3V27EM7UdOfLl5OtCFLTu4R1Ubp1tFE2GJRae9Ct6y5v1rl3NDGi0yOqqzJXFCy1SBKHLBy/XPGfvbJqt0PnrIbs= Date: 13 Aug 2010 18:06:12 -0000 Message-ID: <20100813180612.91396.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <4C6522AE.4020502@tana.it> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Cc: vesely@tana.it Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 18:05:37 -0000 >Possibly, the right syntax is "code=X, code-type=NAICS", rather than naics=X. I would really rather have one set of codes, no matter what they are. The goal for me at least is to have a simple way of asserting things like "this is a bank". If there's an unlimited set of unknown code points, checking the code has now turned from a simple string match into a remote database lookup. > IMHO, such info should be provided by the registrar in the relevant WHOIS No. Why would you assume that all subdomains under the same WHOIS entry would be the same type of organization? Look, for example at HP.COM which I would categorize as a manufacturer of electronic equipment or something like that, whereas SHOPPING.HP.COM is a mail order vendor of office supplies. For that matter, why would you assume that all domains have WHOIS info in the first place? R's, John From ajs@shinkuro.com Fri Aug 13 11:10:28 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 0DC623A635F for ; Fri, 13 Aug 2010 11:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.268 X-Spam-Level: X-Spam-Status: No, score=-101.268 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, J_CHICKENPOX_51=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 N4Y7HpOyIvZa for ; Fri, 13 Aug 2010 11:10:26 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 857263A6805 for ; Fri, 13 Aug 2010 11:10:25 -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 D55971ECB41D for ; Fri, 13 Aug 2010 18:11:01 +0000 (UTC) Date: Fri, 13 Aug 2010 14:11:00 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100813181059.GF68767@shinkuro.com> References: <4C6522AE.4020502@tana.it> <20100813180612.91396.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100813180612.91396.qmail@joyce.lan> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 18:10:28 -0000 On Fri, Aug 13, 2010 at 06:06:12PM -0000, John Levine wrote: > >Possibly, the right syntax is "code=X, code-type=NAICS", rather than naics=X. > > I would really rather have one set of codes, no matter what they are. > The goal for me at least is to have a simple way of asserting things > like "this is a bank". If there's an unlimited set of unknown code > points, checking the code has now turned from a simple string match > into a remote database lookup. I have to agree with this. If we have flexible code types, then we have to have some kind of negotiation for which code type to use (suppose you're introducing a new code type; you'd want to support both code types during the transition). I agree it'd be more flexible, but I think it would be at the cost of complexity that doesn't have a compelling need. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dotis@mail-abuse.org Fri Aug 13 11:19:38 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 4FC133A67F3 for ; Fri, 13 Aug 2010 11:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.023 X-Spam-Level: X-Spam-Status: No, score=-105.023 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_50=0.001, 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 1rjj38NW8-cJ for ; Fri, 13 Aug 2010 11:19:36 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id D6CFD3A682A for ; Fri, 13 Aug 2010 11:19:36 -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 57DD4A946AF for ; Fri, 13 Aug 2010 18:20:11 +0000 (UTC) Message-ID: <4C658CDB.8060006@mail-abuse.org> Date: Fri, 13 Aug 2010 11:20:11 -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: <20100813172212.80598.qmail@joyce.lan> In-Reply-To: <20100813172212.80598.qmail@joyce.lan> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 18:19:38 -0000 On 8/13/10 10:22 AM, John Levine wrote: >>> NAICS has 19746 items combined into different categories ... >> I think it should be as small as possible (but no smaller). -- nsb > As I think I said in an earlier message, NAICS codes are like Dewey > Decimal numbers, more digits give you finer distinctions. If you look > here: > > http://www.census.gov/cgi-bin/sssd/naics/naicsrch?chart=2007 > > You'll see that there are about 25 two-digit areas, which are then > broken down into finer areas. So, for example, 52 is Finance and > Insurance, 522 is Credit Intermediaries and Related Activities, 5221 > is Banks, 5222 is non-bank lenders, and 5223 is Activities Related to > Credit Intermediation such as mortgage brokers. > > My expectation is that reputation services would publish as many > digits as they know, and consumers would use as many digits as they > find useful. So if you're treating all bank-like things the same, > anything that starts with 522 is a bank. On the other hand, if you > find mortgage brokers to be sleazier than banks, you might do > something different with 5223. > > The UN's ISIC, and EU's NACE, which appears to be a mutant version of > ISIC, work roughly the same way: 01 is farming, 01.4 is animal > farming, 01.44 is camels and llamas, and 01.46 is swine. John, The two digit information is of little use, but even when attempting to find meaningful categories that might relate to email, it only becomes more confusing. For example would it be 518210, or 541860. Would a company distributing refrigerator magnets be in the same category as a bulk email distributor? These categories are more related to taxes than something that would involve the Internet. These lists are simply not useful, nor is this number scheme suitable for aggregation. Why would it be important to categorize the specific type of business? A general categories such as financial transactions would cover a large range of services that are likely being phished. However, knowing a domain is prone to being phished might represent a category on its own. ,--- 11 Agriculture, Forestry, Fishing and Hunting 21 Mining, Quarrying, and Oil and Gas Extraction 22 Utilities 23 Construction 31 - 33 Manufacturing 42 Wholesale Trade 44-45 Retail Trade 48-49 Transportation and Warehousing 51 Information 52 Finance and Insurance 53 Real Estate and Rental and Leasing 54 Professional, Scientific, and Technical Services 55 Management of Companies and Enterprises 56 Administrative and Support and Waste Management and Remediation Services 61 Educational Services 62 Health Care and Social Assistance 71 Arts, Entertainment, and Recreation 72 Accommodation and Food Services 81 Other Services (except Public Administration) 92 Public Administration ---- 517 Telecommunications Industries in the Telecommunications subsector group establishments that provide telecommunications and the services related to that activity (e.g., telephony, including Voice over Internet Protocol (VoIP); cable and satellite television distribution services; Internet access; telecommunications reselling services). The Telecommunications subsector is primarily engaged in operating, and/or providing access to facilities for the transmission of voice, data, text, sound, and video. Transmission facilities may be based on a single technology or a combination of technologies. Establishments in the Telecommunications subsector are grouped into four industry groups. The first three are comprised of establishments that operate transmission facilities and infrastructure that they own and/or lease, and provide telecommunications services using those facilities. The distinction among the first three industry groups is the type of infrastructure operated (i.e., wired, wireless, or satellite). The fourth industry group is comprised of establishments that provide support activities, telecommunications reselling services, or many of the same services provided by establishments in the first three industry groups, but do not operate as telecommunications carriers. Establishments primarily engaged as independent contractors in the installation and maintenance of broadcasting and telecommunications systems are classified in Sector 23, Construction. Establishments known as Internet cafes, primarily engaged in offering limited Internet connectivity in combination with other services such as facsimile services, training, rental of on-site personal computers, game rooms, or food services are classified in Subsector 561, Administrative and Support Services, or Subsector 722, Food Services and Drinking Places, depending on the primary activity. 518210 Data Processing, Hosting, and Related Services This industry comprises establishments primarily engaged in providing infrastructure for hosting or data processing services. These establishments may provide specialized hosting activities, such as web hosting, streaming services or application hosting, provide application service provisioning, or may provide general time-share mainframe facilities to clients. Data processing establishments provide complete processing and specialized reports from data supplied by clients or provide automated data processing and data entry services. Illustrative Examples: Application hosting Application service providers Computer input preparation services Computer time rental Microfilm imaging services Optical scanning services Web hosting Cross-References. Establishments primarily engaged in-- • Providing text processing and related document preparation activities--are classified in Industry 561410, Document Preparation Services; • Providing on-site management and operation of a clients’ data-processing facilities-- are classified in U.S. Industry 541513, Computer Facilities Management Services; • Providing Internet access services in combination with web hosting--are classified in U.S. Industry 518111, Internet Service Providers; • Operating web search portals--are classified in U.S. Industry 518112, Web Search Portals; • Providing access to computers and office equipment, as well as other office support services--are classified in Industry 56143, Business Service Centers; • Processing financial transactions, such as credit card transactions--are classified in Industry 522320, Financial Transactions Processing, Reserve, and Clearinghouse Activities; and • Providing payroll processing services--are classified in U.S. Industry 541214, Payroll Services. 541860 Direct Mail Advertising This industry comprises establishments primarily engaged in (1) creating and designing advertising campaigns for the purpose of distributing advertising materials (e.g., coupons, flyers, samples) or specialties (e.g., key chains, magnets, pens with customized messages imprinted) by mail or other direct distribution; and/or (2) preparing advertising materials or specialties for mailing or other direct distribution. These establishments may also compile, maintain, sell, and rent mailing lists. '--- -Doug From fergdawgster@gmail.com Fri Aug 13 11:46:59 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 DB7813A6359 for ; Fri, 13 Aug 2010 11:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 UaeNnF2IReha for ; Fri, 13 Aug 2010 11:46:56 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 420623A6850 for ; Fri, 13 Aug 2010 11:46:56 -0700 (PDT) Received: by wwj40 with SMTP id 40so2741250wwj.13 for ; Fri, 13 Aug 2010 11:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/EeVPx5c2jnc0c6a6EylnYwRlfelg+gyNI4OzDx2Rd0=; b=aawOPVIAlQG25WgmlGS4IekeAfDtAVFIZOgRVut0hpQzaAjk3K65ivsxOdebIbKa/h CFxQ5R+e0+fbxsWOvibWOvl7y5JGVWyiqPhi1Cd/C+M2T/syxyOPB3Qo0sFfZNnQcMmn UX3nH6V5QdiW8fqlK0+a3fUMa7hgimqAKvt1g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=alMJlk3atEiYK0TPPUbtw5pZN6J9ftzdx8k27cZORXj3mN2cyK0Xe2+4NK+sWGXPsk 62aGfxg6Q6bpyeqqG62ToMaCsKyPvCMXWdd9sN+aIHO7jMIupLnhHlTLoYrSUAh6GM0S NH9m6+b+4OXf7yBYPOBXPqHV3xHjNaYw+enIE= MIME-Version: 1.0 Received: by 10.227.155.3 with SMTP id q3mr1601985wbw.130.1281725252617; Fri, 13 Aug 2010 11:47:32 -0700 (PDT) Received: by 10.216.18.20 with HTTP; Fri, 13 Aug 2010 11:47:32 -0700 (PDT) In-Reply-To: <20100813180612.91396.qmail@joyce.lan> References: <4C6522AE.4020502@tana.it> <20100813180612.91396.qmail@joyce.lan> Date: Fri, 13 Aug 2010 11:47:32 -0700 Message-ID: From: Paul Ferguson To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org, vesely@tana.it Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 18:46:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Aug 13, 2010 at 11:06 AM, John Levine wrote: > > >> IMHO, such info should be provided by the registrar in the relevant >> WHOIS > > No. Why would you assume that all subdomains under the same WHOIS > entry would be the same type of organization? > > Look, for example at HP.COM which I would categorize as a manufacturer > of electronic equipment or something like that, whereas > SHOPPING.HP.COM is a mail order vendor of office supplies. > > For that matter, why would you assume that all domains have WHOIS info > in the first place? ...or that the information already there is correct? The domain WHOIS is already heavily polluted with incorrect or outdated data. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.3 (Build 5003) wj8DBQFMZZM9q1pz9mNUZTMRAmfBAJ9NhH0HxXJomuUNPNbZ8qbje8U6sQCcCpou 0D08zyADAe+xdaYj3uhJpDw=3D =3D2Vkd -----END PGP SIGNATURE----- --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From jdfalk-lists@cybernothing.org Fri Aug 13 12:37:53 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 01F273A69A2 for ; Fri, 13 Aug 2010 12:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9Cskhtb7S34 for ; Fri, 13 Aug 2010 12:37:51 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id B7B603A697A for ; Fri, 13 Aug 2010 12:37:51 -0700 (PDT) Received: from [192.168.11.34] (c-76-126-155-21.hsd1.ca.comcast.net [76.126.155.21]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7DJcP9a007119 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 13 Aug 2010 12:38:27 -0700 References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> <4C63CE8A.2010102@tana.it> <09DBFDD5-BB31-43A0-9D6C-AF7CA535CD35@guppylake.com> In-Reply-To: <09DBFDD5-BB31-43A0-9D6C-AF7CA535CD35@guppylake.com> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <2F2861E4-3778-4EE4-AAA2-9559B2A31D91@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Fri, 13 Aug 2010 12:38:24 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] scope question - what apps? 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: Fri, 13 Aug 2010 19:37:53 -0000 On Aug 13, 2010, at 4:14 AM, Nathaniel Borenstein wrote: > On Aug 12, 2010, at 6:35 AM, Alessandro Vesely wrote: >=20 >> Many services authenticate users based on their email addresses. For = example, someone can open an account at gmail, use it to subscribe to a = wiki web site, and then spam that wiki. I'm not sure whether Nathaniel = means this kind of antisocial behavior. What should gmail do? >=20 > It's not what I was thinking of, but it's another good example. I = just doubt that, over the long term, we'll be able to maintain the = notion of different reputations in different contexts for a single = domain/IP address/email address. If you knew that something had a bad = reputation in one context, and no reputation in another context, = mightn't the former reputation be better than nothing in the latter = context? We've seen that in a few cases already, the most common example being = use of email dnsbls to block irc or http traffic. The CBL specifically = mentions this in their terms and conditions: "If you want to use the CBL to block protocols other than SMTP on port = 25 (ie: IRC), realize this is officially UNSUPPORTED by the CBL team. We appreciate that this is a useful thing to do, but you MUST NOT = mention the CBL as being the source of a block and you should be = prepared to provide "first contact" assistance for users encountering a = block and potentially whitelisting on your service. It should be absolutely clear that there will be a potentially large = number of affected users who, through no fault of their own, will NOT be = able to delist due to NAT, dynamic IPs, or other similar issues. Anyone = using the CBL for blocking IRC, blog comments or whatever needs to know = that they will get collateral damage and they will either have to manage = that themselves with whitelisting or live with it." http://cbl.abuseat.org/tandc.html So the context isn't just a nice-to-have; it may be something the = reputation provider feels is absolutely necessary. > Perhaps instead of talking about reputations for each service, we = should think about generic reputations with details about the kinds of = negative information they're based on? As in "Reputation =3D 3.1/100; = abuse-types: phishing=3D7,spam=3D325,double-parking=3D1" (Oh, goody, = another registry.) We might also worry about representing the recency = of the bad events, too. This is complex stuff, and I'm not sure we can = (or should) reduce it to a really simple score.=20 Could work. Another axis I've seen is sometimes called "certainty," and = includes some measure of recency along with the general reliability of = particular data sources. But in practice, I haven't come across any reputation clients who do = their own math in real time based on these multiple axes. They just = want to know whether or not to accept the message, or the connection. = Everything else is left in the secret sauce realm. From jdfalk-lists@cybernothing.org Fri Aug 13 12:45:11 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 D190E3A69A6 for ; Fri, 13 Aug 2010 12:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 b1EG6bV4cDNA for ; Fri, 13 Aug 2010 12:45:10 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id BC2443A69A2 for ; Fri, 13 Aug 2010 12:45:09 -0700 (PDT) Received: from [192.168.11.34] (c-76-126-155-21.hsd1.ca.comcast.net [76.126.155.21]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7DJjio0007214 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 13 Aug 2010 12:45:46 -0700 References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> In-Reply-To: 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: Fri, 13 Aug 2010 12:45:43 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: [domainrep] categories (was Re: A sketch of a small query reputation system) 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: Fri, 13 Aug 2010 19:45:12 -0000 On Aug 12, 2010, at 7:39 AM, John R. Levine wrote: >> In any case, this is all extremely premature. I think you >> first need to say why an organisation classification value >> is generally useful before its encoding becomes an issue. >=20 > Sigh. As I think I've said at least three times now, some mail = systems may want to handle incoming mail differently if they know it's = from a particular kind of organization, with banks and governments being = the usual examples. >=20 > This isn't hypothetical. When we were talking about this at DAC, = people who handle rather a lot more mail than you or I do said this = would be useful. For large-scale filtering operators & truly creative mail UI developers, = accurately categorizing mail is the holy grail AFTER the holy grail of = getting all the spam out of the way. Which categories are interesting can vary depending on who you're = talking to and who they've talked to recently and how much caffeine = they've had, which I believe is why DAC chose such a broad list of = categories. From sm@resistor.net Fri Aug 13 13:21:17 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 7DCF63A6A34 for ; Fri, 13 Aug 2010 13:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.711 X-Spam-Level: X-Spam-Status: No, score=-102.711 tagged_above=-999 required=5 tests=[AWL=-0.112, 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 SnXZA2+TkI4L for ; Fri, 13 Aug 2010 13:21:15 -0700 (PDT) Received: from ns1.qubic.net (ns1.qubic.net [208.69.177.116]) by core3.amsl.com (Postfix) with ESMTP id 0E1BB3A6852 for ; Fri, 13 Aug 2010 13:21:15 -0700 (PDT) Received: from SUBMAN.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.5.Alpha0/8.14.5.Alpha0) with ESMTP id o7DKLe38002976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Aug 2010 13:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1281730910; x=1281817310; bh=lFppcfjDFK2b1koFSIh9yzRKlza2Z8VOWedlTvj3J6I=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=TMOnz7iNSj2aYjEgm+k6X1BET2AbUYk5t2DG/z2LiSd1727hYS2Q3mpEuDDGwFkY2 6bNr0JqRFeQR9hESSQv7CocWpUprSnBBZguwlbJHh1PhxaMH7SYz31JJwHp6OFZcV1 Or7H2whyYwY5YQeK6uJJOadycHGtt01ELATlpVwk= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1281730910; x=1281817310; bh=lFppcfjDFK2b1koFSIh9yzRKlza2Z8VOWedlTvj3J6I=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=q1cBQMhZZYzO9S2IubtZ/i0lFvzQ4IyH3eSXEHEJmtksMdwmFFv1SLKgBlzt1S5KC U9ZqO+Nog9t8D6rjAWCvyFpTqCZ27xZbHIv17IAPhA07kUB+khDtQKM0Db17OAWBwZ 9QfvernIHjE6NV+05m2x4FwrRnjO0Po6wkgdebGs= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=Px3617dF6TebX44oCYzUVvV10z6+Yq91mXcCjuR49jqf2ArTKoJk4aJgcGQzZwRDf BksZ2hojQGWSMVonZLLY1+24lMBuTUBZZfSdqcw0xhaeO/hyfYrz1jphmciPz1WzI4U Ljf6lpfKFkIlWPBC5PZL04z1VBd3OfITBN24bE8= Message-Id: <6.2.5.6.2.20100813130708.05bcba50@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 13 Aug 2010 13:11:38 -0700 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <20100812011536.52399.qmail@joyce.lan> <4C634D2C.2010109@cs.tcd.ie> <4C63B14C.5060202@cs.tcd.ie> <4C644844.3020700@cs.tcd.ie> <20100812202753.GJ64251@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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: Fri, 13 Aug 2010 20:21:17 -0000 Hi Murray, At 13:31 12-08-10, Murray S. Kucherawy wrote: >For that matter, why does everyone think ASCII is okay? Isn't the >"A" part objectionable? ASCII is not okay. Some people prefer XML. :-) >I'd be perfectly fine with any table matching integers to business >types, no matter who comes up with it. I guess that's why I don't >get the objection. There must be something about that particular >data set that I just don't get yet. You could use the European NACE classification or the International Standard Industrial Classification of All Economic Activities (ISIC). Regards, -sm From nsb@guppylake.com Sun Aug 15 08:41:35 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 794AD3A684C for ; Sun, 15 Aug 2010 08:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] 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 a7aKX0r1FZGr for ; Sun, 15 Aug 2010 08:41:34 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 557543A6820 for ; Sun, 15 Aug 2010 08:41:34 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OkfY2-0000xS-Q1; Sun, 15 Aug 2010 11:54:59 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20100813172212.80598.qmail@joyce.lan> Date: Sun, 15 Aug 2010 11:42:05 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> References: <20100813172212.80598.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] A sketch of a small query reputation system 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: Sun, 15 Aug 2010 15:41:35 -0000 On Aug 13, 2010, at 1:22 PM, John Levine wrote: >>> NAICS has 19746 items combined into different categories ... >=20 >> I think it should be as small as possible (but no smaller). -- nsb >=20 > As I think I said in an earlier message, NAICS codes are like Dewey > Decimal numbers, more digits give you finer distinctions... I'm sorry, I missed that. The possibility of using more digits for more = specificity is very appealing, best of both worlds. I don't really have any remaining objection to NAICS, though I = sympathize with those bothered by the "NA." We could give it a new = name, though, that wouldn't be a first. =20 However, I'm concerned about the evolution of our *use* of any such = taxonomy. Anything like NAICS will have a change process and other = needs that might not suffice for an Internet protocol. (Searching the = codes for "software" doesn't give me an appropriate classification for a = cloud/SOA/old-AOL/Tymshare type of company. That level of detail could = be important when we start to worry about the reputations of reputation = authorities. And we will.) One approach would be to start with NAICS-or-equivalent, but to give = ourselves a lightweight hook to fork/augment its evolution, perhaps with = an IETF registry or two, if it proves necessary. -- Nathaniel From nsb@guppylake.com Sun Aug 15 08:51:28 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 3FB1C3A684C for ; Sun, 15 Aug 2010 08:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 pg0MZdQ20W9H for ; Sun, 15 Aug 2010 08:51:27 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 6CAD33A659C for ; Sun, 15 Aug 2010 08:51:27 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1Okfhc-00022e-4Y; Sun, 15 Aug 2010 12:04:52 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <2F2861E4-3778-4EE4-AAA2-9559B2A31D91@cybernothing.org> Date: Sun, 15 Aug 2010 11:51:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8A1FAF3B-9826-4ED8-8DC2-7C3C29BC53E5@guppylake.com> References: <4C6062CC.2030406@cs.tcd.ie> <4C60637B.3090604@att.com> <4C617C05.3020502@mail-abuse.org> <4C61A49E.7080809@mail-abuse.org> <4C63CE8A.2010102@tana.it> <09DBFDD5-BB31-43A0-9D6C-AF7CA535CD35@guppylake.com> <2F2861E4-3778-4EE4-AAA2-9559B2A31D91@cybernothing.org> To: J.D. Falk 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] scope question - what apps? 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: Sun, 15 Aug 2010 15:51:28 -0000 On Aug 13, 2010, at 3:38 PM, J.D. Falk wrote: > But in practice, I haven't come across any reputation clients who do = their own math in real time based on these multiple axes. They just = want to know whether or not to accept the message, or the connection. = Everything else is left in the secret sauce realm. This is a really good point. Most users would prefer a binary answer. = The only ones I can think of who want more info are those who explicitly = want to take in reputation data from multiple sources, which means = they're aggregating data in order increase their confidence level or to = resell it. I don't think even they really need a whole lot of fine = grain distinctions, simply heterogeneous conclusions to hedge their best = with multiple authorities -- the more different the secret sauces, the = better. If those are the real clients for open reputation information exchange, = we could make this vastly simpler. A single integer from 1 to 100 = might suffice. Vendors could have vastly more complex systems = internally, but a couple digits of precision could be plenty for the = needs of the aggregators, who are basically hedging against systemic = errors rather than doing fine-grained re-analysis. -- Nathaniel From johnl@iecc.com Sun Aug 15 10:09:01 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 32C6B3A68E4 for ; Sun, 15 Aug 2010 10:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.948 X-Spam-Level: X-Spam-Status: No, score=-109.948 tagged_above=-999 required=5 tests=[AWL=1.251, 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 yk6VNQMSKqDl for ; Sun, 15 Aug 2010 10:09:00 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id A73EE3A67D4 for ; Sun, 15 Aug 2010 10:08:59 -0700 (PDT) Received: (qmail 3134 invoked from network); 15 Aug 2010 17:09:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=ylIN8srh+jbZjVKlkXfmj+HBMRmJl79s9jl08nzgt58=; b=nVDTUI9dVAl3RbuvsnIv2nf22ZQPGW+kjEyafCdmRH/baz1Wr4vYFz30vUJ9bSKhcMGS89BNADjh2mJ+Cp+TdWDRp0L/brjB2BSC+GUWsD1RUh9poL37WRPbjDcsnqQt/vgWbfq+W5cS+xHiKNSuvdrSFIlHMEW8fkR4VgkBY6E= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Aug 2010 17:09:12 -0000 Date: 15 Aug 2010 13:09:34 -0400 Message-ID: From: "John R. Levine" To: "Nathaniel Borenstein" In-Reply-To: <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] A sketch of a small query reputation system 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: Sun, 15 Aug 2010 17:09:01 -0000 > However, I'm concerned about the evolution of our *use* of any such taxonomy. Anything like NAICS will have a change process and other needs that might not suffice for an Internet protocol. (Searching the codes for "software" doesn't give me an appropriate classification for a cloud/SOA/old-AOL/Tymshare type of company. That level of detail could be important when we start to worry about the reputations of reputation authorities. And we will.) They do change it from time to time. The current NAICS is 2007, previous one was 2002. They don't unpublish the older versions and lots of people still use SIC, its 1990s predecessor. I sympathize with concerns that the categories don't match what we're likely to use them for. I think NAICS is a little closer than ISIC (which has seprate codes for goat and camel farms, but divides data processing into "web portals" and everything else) but neither is perfect. Nonetheless, it seems very unlikely that this particular group, with little expertise in industrial taxonomy, could come up with a set of categories that worked better than ISIC or NAICS so as I've said, I'd pick one and use it, at least for straw man purposes. R's, John From johnl@iecc.com Sun Aug 15 11:47:57 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 EFC163A6407 for ; Sun, 15 Aug 2010 11:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.966 X-Spam-Level: X-Spam-Status: No, score=-109.966 tagged_above=-999 required=5 tests=[AWL=1.233, 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 Jx63+1zoB1vS for ; Sun, 15 Aug 2010 11:47:56 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 9C63D3A6403 for ; Sun, 15 Aug 2010 11:47:56 -0700 (PDT) Received: (qmail 41000 invoked from network); 15 Aug 2010 18:48:32 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 15 Aug 2010 18:48:32 -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=k1008; olt=johnl@user.iecc.com; bh=uXJT1ar6LGV+VvZyuiq3Jf7PKfa5heoU4BHO7WOqrl8=; b=TEtiJ3fN2nauG2PILOYFH7qXXygtapdbrj0dQEGOAoVdZgJ7t9IrJY8cQqWSSy1TbqVqXUbL4EoEbTc/ETOwaTjPw75qm7iCScSxIN25vPiqTqECUOU4XGXXoDEbsAhGPiqdIuKxO6An7Rsbsebfgwf53wLcTGxACFHkl8u6QOk= Date: 15 Aug 2010 18:48:31 -0000 Message-ID: <20100815184831.39481.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <8A1FAF3B-9826-4ED8-8DC2-7C3C29BC53E5@guppylake.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] scope question - what apps? 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: Sun, 15 Aug 2010 18:47:58 -0000 >This is a really good point. Most users would prefer a binary >answer. The only ones I can think of who want more info are those >who explicitly want to take in reputation data from multiple sources, >which means they're aggregating data in order increase their >confidence level or to resell it. Well, there's always Spamassassin, which can mix just about anything into the score. R's, John From nsb@guppylake.com Mon Aug 16 03:05:43 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 D7A4B3A6994 for ; Mon, 16 Aug 2010 03:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 MYKcFkLDk-UJ for ; Mon, 16 Aug 2010 03:05:43 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id EE2E03A687C for ; Mon, 16 Aug 2010 03:05:42 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1Okwmb-0006uk-JO; Mon, 16 Aug 2010 06:19:10 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20100815184831.39481.qmail@joyce.lan> Date: Mon, 16 Aug 2010 06:06:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4CC0DFF8-EB14-49CE-A300-27DB67813E76@guppylake.com> References: <20100815184831.39481.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: [domainrep] Scoring Precision (was Re: scope question - what apps?) 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, 16 Aug 2010 10:05:43 -0000 On Aug 15, 2010, at 2:48 PM, John Levine wrote: >> This is a really good point. Most users would prefer a binary >> answer. The only ones I can think of who want more info are those >> who explicitly want to take in reputation data from multiple sources, >> which means they're aggregating data in order increase their >> confidence level or to resell it. >=20 > Well, there's always Spamassassin, which can mix just about anything = into > the score. Sure, that's my first category ("want to in reputation data from = multiple sources"). Spamassassin and its ilk can in fact be configured = to compute scores based on degrees of precision that aren't really = meaningful. I'm not sure at what point increased precision becomes a = confusion of precision with accuracy, but I doubt it does much harm. So = I guess my preference is a scheme that allows plenty of precision, but = acknowledges that most consumption of the scores will only look at the = most significant digit or two. -- Nathaniel= From nsb@guppylake.com Mon Aug 16 03:05:44 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 646A03A687C for ; Mon, 16 Aug 2010 03:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.722 X-Spam-Level: X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_05=-1.11] 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 Th4rpfw+lFW9 for ; Mon, 16 Aug 2010 03:05:43 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 710393A6982 for ; Mon, 16 Aug 2010 03:05:43 -0700 (PDT) Received: from 184-202-77-110.pools.spcsdns.net ([184.202.77.110] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1Okwmc-0006uk-M1; Mon, 16 Aug 2010 06:19:10 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: Date: Mon, 16 Aug 2010 06:06:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> To: John R. 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: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 10:05:44 -0000 On Aug 15, 2010, at 1:09 PM, John R. Levine wrote: > Nonetheless, it seems very unlikely that this particular group, with = little expertise in industrial taxonomy, could come up with a set of = categories that worked better than ISIC or NAICS so as I've said, I'd = pick one and use it, at least for straw man purposes. I agree completely, I just think it might be worth having a way for us = to augment it with distinctions we don't want to wait 5 years for, such = as discriminating between email marketers, cloud service providers, = email security vendors, etc. We may not want to wait for a = twice-a-decade revision to give us those categories. In fact, NAICS may = never make those distinctions, so specific are they to our needs, which = is why it might best be viewed as an IETF extension to NAICS. -- = Nathaniel= From stephen.farrell@cs.tcd.ie Mon Aug 16 03:19:44 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 DE11D3A6866 for ; Mon, 16 Aug 2010 03:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 nFtnl+Z+gC8z for ; Mon, 16 Aug 2010 03:19:41 -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 C66563A6898 for ; Mon, 16 Aug 2010 03:19:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 095EB3E405F; Mon, 16 Aug 2010 11:20:14 +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=1281954013; bh=sGUTnxHK6KT39Z 1jUHtbCZq6YAz6o6zeviiyQF6gNeY=; b=q+2NjyDIcgXy6p2J7orGJmWEwtshMk I3ia24F4jWpaCEme+8lJzHk4K6EtnqCbZki4/+6+DHIF3qhdtuVjTYSo4TbhDgrm EsbNyOsIDNMOFR+BLO+Vyfq/FQtk9L7n6gWi89be8laYCj3yexy6XovOK6TTxL6U droEEXCB4ZpUAN/eckaTwuQL/0PSoO/DmOO81ZQrR7wQSKnXct2MsqZG03LqEPBf x2CyxbQiFfvaYLEq51ueHGWEBVkbgHjPtK/dYialI8O4bHy5y/HAEXPaixrIP59Z Zj/YLWKSNZmuEeN6SwZ9nHhlp+mtRd21nMVOuR8XtNCScy26n+pov1jg== 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 LpR5V1hnTPxT; Mon, 16 Aug 2010 11:20:13 +0100 (IST) Received: from [134.226.36.137] (stephen-samy.dsg.cs.tcd.ie [134.226.36.137]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 38B1E3E4063; Mon, 16 Aug 2010 11:20:12 +0100 (IST) Message-ID: <4C6910DB.1050202@cs.tcd.ie> Date: Mon, 16 Aug 2010 11:20:11 +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: Nathaniel Borenstein References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> In-Reply-To: <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "John R. Levine" , domainrep@ietf.org Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 10:19:44 -0000 On 16/08/10 11:06, Nathaniel Borenstein wrote: > > On Aug 15, 2010, at 1:09 PM, John R. Levine wrote: > >> Nonetheless, it seems very unlikely that this particular group, with little expertise in industrial taxonomy, could come up with a set of categories that worked better than ISIC or NAICS so as I've said, I'd pick one and use it, at least for straw man purposes. > > I agree completely, I don't :-) > I just think it might be worth having a way for us to augment it with distinctions we don't want to wait 5 years for, such as discriminating between email marketers, cloud service providers, email security vendors, etc. We may not want to wait for a twice-a-decade revision to give us those categories. In fact, NAICS may never make those distinctions, so specific are they to our needs, which is why it might best be viewed as an IETF extension to NAICS. -- Nathaniel I think Murray's suggestion (make NAICS some kind of tagged option) caters for this. If folks play with NAICS but then need something else then they can do that. Personally, I don't think these industrial classifications will useful for very long, but I guess so long as we can change, there's no harm in trying. S. From vesely@tana.it Mon Aug 16 04:25:36 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 E10173A698B for ; Mon, 16 Aug 2010 04:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.212 X-Spam-Level: X-Spam-Status: No, score=-2.212 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, 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 w+3Bt2isRtCg for ; Mon, 16 Aug 2010 04:25:35 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 01D3E3A68B9 for ; Mon, 16 Aug 2010 04:25:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1281957966; bh=u6wsYFiGulNU7JFNeFBPbKZ0J4VZAIqkAwNy1J2hFXE=; l=2348; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=SdHCHYo5vJQFZNBfxiwssJrJH+2c2AhnR12L6/dvX2nYnpxFJS4006ADUSI4RWANn n05CsLuVhcDsHs0+0akCheerktYpniU5b8Wl8yoik5ENJVEl62MgSBv9LQzCi3iyZB OLhjqfzLi19MNfABfTIlnLzde/puzEtY841hWUCY= Received: from 1-38-169-90.live.vodafone.in (93-32-190-234.ip34.fastwebnet.it [93.32.190.234]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 16 Aug 2010 13:26:06 +0200 id 00000000005DC036.000000004C69204E.00003C29 Message-ID: <4C692051.8070006@tana.it> Date: Mon, 16 Aug 2010 13:26:09 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> In-Reply-To: <4C6910DB.1050202@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 11:25:37 -0000 Stephen Farrell wrote: > On 16/08/10 11:06, Nathaniel Borenstein wrote: >> On Aug 15, 2010, at 1:09 PM, John R. Levine wrote: >> >>> Nonetheless, it seems very unlikely that this particular >>> group, with little expertise in industrial taxonomy, could >>> come up with a set of categories that worked better than ISIC >>> or NAICS so as I've said, I'd pick one and use it, at least >>> for straw man purposes. >> >> I agree completely, > > I don't :-) I'd agree on using it for straw man purposes _only_. BTW, this would imply not using the term "NAICS" at all, and thus clears the NA objection too. >> I just think it might be worth having a way for us to augment it with >> distinctions we don't want to wait 5 years for, such as discriminating >> between email marketers, cloud service providers, email security >> vendors, etc. Doug has exemplified the inadequacy of NAICS very clearly. See http://www.ietf.org/mail-archive/web/domainrep/current/msg00147.html > I think Murray's suggestion (make NAICS some kind of tagged option) > caters for this. If folks play with NAICS but then need something > else then they can do that. Personally, I don't think these industrial > classifications will useful for very long, but I guess so long as > we can change, there's no harm in trying. A possible harm is inertia. One thing that this particular group could do to preempt it is to define an initial set of one-digit classes and an easy procedure for augmenting it. The initial classification should be very simple and obvious. For example, "O" open, Internet-oriented domains. They give web (wiki or blog) or email (mailboxes) access to unidentified, possibly duplicated users. "C" closed organizations. They grant mailboxes or web access only to employees, affiliates, or other well-identified entities. Their technical staff may contact users for security issues. As for the augmenting procedure, it has to take into account the very classification process. Who will assign such code to domains, and based on what sort of evidence or criteria? Note that NAICS or similar classifications may well be mentioned in the augmenting procedure. We could import whole branches, as needed, from whatever classification. From ajs@shinkuro.com Mon Aug 16 14:52: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 E166D3A6781 for ; Mon, 16 Aug 2010 14:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.572 X-Spam-Level: X-Spam-Status: No, score=-101.572 tagged_above=-999 required=5 tests=[AWL=1.027, 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 014CMe9bYap6 for ; Mon, 16 Aug 2010 14:52:23 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id E24453A6765 for ; Mon, 16 Aug 2010 14:52:22 -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 02BEF1ECB408 for ; Mon, 16 Aug 2010 21:52:57 +0000 (UTC) Date: Mon, 16 Aug 2010 17:52:56 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100816215255.GB86057@shinkuro.com> References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C692051.8070006@tana.it> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 21:52:24 -0000 On Mon, Aug 16, 2010 at 01:26:09PM +0200, Alessandro Vesely wrote: > A possible harm is inertia. One thing that this particular group could > do to preempt it is to define an initial set of one-digit classes and an > easy procedure for augmenting it. I can't quite tell whether you're proposing that we start with something we're going to build, but make one taxonomy; or whether you're suggesting we standardize a procedure for augmenting a base set of classes. The thing that worries me about the latter suggestion is that we'll end up with classification schemes that are local only: everyone will have their pet classes. Since we're supposed to be about interoperability at the IETF, it seems to me that it would be better to have some proposal that converges on a single taxonomy. In any case, given that the IETF doesn't attract taxonomic expertise the way other SDOs do, it seems to me it would be better to adopt some external classification as the basis for work than to go off and make our own. I'm particularly concerned with suggestions like this: > The initial classification should be very simple and obvious. Obvious to one person is obscure to another. The example you gave was to me much less compelling than some other classes with which I'd naturally divide up the universe, and I think we could spend a long time arguing about which "obvious" classification was the one true one. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From johnl@iecc.com Mon Aug 16 16:15:33 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 F0DC33A6827 for ; Mon, 16 Aug 2010 16:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.955 X-Spam-Level: X-Spam-Status: No, score=-109.955 tagged_above=-999 required=5 tests=[AWL=1.244, 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 SGiRDXoDe+x5 for ; Mon, 16 Aug 2010 16:15:33 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id EB1763A681D for ; Mon, 16 Aug 2010 16:15:32 -0700 (PDT) Received: (qmail 29439 invoked from network); 16 Aug 2010 23:16:08 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 16 Aug 2010 23:16:08 -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=k1008; olt=johnl@user.iecc.com; bh=2VLJs3R77Rfk7gJ7mEDN2lYDaFUlkyTWWN81S7bnm84=; b=jpW174GfbTGHQmhpqCwyj6/Gr1Kf1DkaBhy6QpWAE8Wz19rvTS1G4atu5LXgxZkUeirujaXuPwzOhyXfpz5SRzaeLUNCLDKc/6JTahpMpj86ltNCEBOWLv7A7b1USTRkfR3u2gsdPtjH8mS9P1LrclT+KJJzY9rQEK+wBUrzjIk= Date: 16 Aug 2010 23:16:07 -0000 Message-ID: <20100816231607.29638.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <20100816215255.GB86057@shinkuro.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 23:15:34 -0000 >> The initial classification should be very simple and obvious. At DAC, when we were working on VBR, at one point we had a detailed taxonomy of mail types, based on the extensive experience of everyone involved, and we ended up throwing everything out other than mailing list, because it wasn't clear to anyone that the taxonomy solved any problems. I'm pretty sure that a reputation system that told me whether a sender was a bank or a government would be useful. I'm pretty sure that the distinction between a camel farmer and a pig farmer is not. Between that I'm not sure. This tells me that we need a place holder, and we can worry about the details when we have more experience and more comments from people who run real mail systems. R's, John From stephen.farrell@cs.tcd.ie Mon Aug 16 16:19: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 74A4B3A685B for ; Mon, 16 Aug 2010 16:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=-0.180, 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 dJxgUhcCR6yb for ; Mon, 16 Aug 2010 16:19:26 -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 7C9713A6830 for ; Mon, 16 Aug 2010 16:19:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 13B483E4085; Tue, 17 Aug 2010 00:20:00 +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=1282000799; bh=zJvKAAK2tA9jL4 aUfAlkdWvbOoiNE5qn3NVAdrMQEIk=; b=b6zZfmJhcpdjahOC9pI0FVZRDbdy9l n44Cfp9eW7mnuwMQbeAxwO85+0WSORZDv/n/YCMcalugwS3+I27asJR2Go1cs0uu 6e1s5QrVe0Jt3TsBNDAlGJLKSIY4Iy+bQt56kMCwFPvdcbKceacbGWOoVqmmvQy3 liJO0JHS9xhnx5W8+6mmXMtWZEreKYeKxKJ0r/vZPurk+cz8XSoPUvPpZAT/NGzz OOoFeOyM4C++DjCADD70D+I6THGqJEnTOQvVyWk8CJgOO7BDKMXRRqSGYMUyKYB6 NC4Fix5G4RzGaG1mFhEqUliQQ5UWPhuXeMqze9P7c/Wa2Fy65tenIjFg== 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 hZ8AB0jEOBJR; Tue, 17 Aug 2010 00:19:59 +0100 (IST) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id AFF823E4083; Tue, 17 Aug 2010 00:19:58 +0100 (IST) Message-ID: <4C69C79D.9010802@cs.tcd.ie> Date: Tue, 17 Aug 2010 00:19:57 +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: John Levine References: <20100816231607.29638.qmail@joyce.lan> In-Reply-To: <20100816231607.29638.qmail@joyce.lan> 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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 23:19:27 -0000 On 17/08/10 00:16, John Levine wrote: > I'm pretty sure that a reputation system that told me whether a sender > was a bank or a government would be useful. I'm pretty sure that the > distinction between a camel farmer and a pig farmer is not. Between > that I'm not sure. This tells me that we need a place holder, and we > can worry about the details when we have more experience and more > comments from people who run real mail systems. I do agree with that, esp. the "not sure" part. However, I'd s/mail systems/mail and other systems/ if we conclude this is about more than mail. (And I guess sender would be replaced with something else as well for non-mail apps.) S. From jdfalk-lists@cybernothing.org Mon Aug 16 16:29: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 CAB263A685B for ; Mon, 16 Aug 2010 16:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP-bCRdMaSiJ for ; Mon, 16 Aug 2010 16:29:27 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id CAF5E3A6840 for ; Mon, 16 Aug 2010 16:29:26 -0700 (PDT) Received: from rpny-mblumb0911.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7GNTxfY006462 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 16 Aug 2010 16:30:01 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7GNTxfY006462 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282001402; bh=sRkiUdHTuPzjpi1+FLTA9MV7kHZfHtyMnbGOtCQRQ yA=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=eMES/WAtYaGOYVHO elJqz1Awct3SshcaG07irJcnrkiuozM2f0VstxelbzUXjtKTdbhThefAdXGl+4owEtD lyflEcpmBtaj3hWAkvlhj4veSKLpghrtlCn6eOz99/yfUXbMQF9Tx4eW4WjLG/bPLSm K0AiB4DJC0Pugh+1Yx8Mc= References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> In-Reply-To: <4C6910DB.1050202@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <83FF4685-3C5B-425E-8516-081698B5BD5C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Mon, 16 Aug 2010 16:29:53 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 23:29:30 -0000 Speaking as co-chair, for whatever weight that may carry on a pre-WG = mailing list.... On Aug 16, 2010, at 3:20 AM, Stephen Farrell wrote: > I think Murray's suggestion (make NAICS some kind of tagged option) > caters for this. If folks play with NAICS but then need something > else then they can do that. Personally, I don't think these industrial > classifications will useful for very long, but I guess so long as > we can change, there's no harm in trying. It's hard to argue against the need for standard classifications, and = even harder to argue against the need to change or update those = classifications as our needs evolve. But as we've already seen on this list, different people have very = different criteria for differentiation of mail streams. We could very = easily end up arguing about definitions for decades without ever = reaching a single taxonomy that'll work for everyone. So I'd like to expand from Murray's original suggestion, and ask if we = could please agree that: 1. the ability to reference a standard taxonomy of sender types is = worthy of further discussion, and 2. the specific contents of said taxonomy are out of scope for this = group. If there's a strong desire for an IETF effort to create such a taxonomy, = perhaps a separate (but obviously complimentary) effort could be spun = up. However, I don't think the domainrep effort has to wait for it. Any strong opposition? Does this need a formal call for consensus? From dotis@mail-abuse.org Mon Aug 16 16:51:52 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 C12A63A68E4 for ; Mon, 16 Aug 2010 16:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.305 X-Spam-Level: X-Spam-Status: No, score=-106.305 tagged_above=-999 required=5 tests=[AWL=0.294, 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 Zf-vP+dMLSKf for ; Mon, 16 Aug 2010 16:51:51 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id D66333A685B for ; Mon, 16 Aug 2010 16:51:51 -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 CB55EA9450C for ; Mon, 16 Aug 2010 23:52:23 +0000 (UTC) Message-ID: <4C69CF37.6060608@mail-abuse.org> Date: Mon, 16 Aug 2010 16:52:23 -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: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> In-Reply-To: <20100816215255.GB86057@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 16 Aug 2010 23:51:52 -0000 On 8/16/10 2:52 PM, Andrew Sullivan wrote: > On Mon, Aug 16, 2010 at 01:26:09PM +0200, Alessandro Vesely wrote: >> A possible harm is inertia. One thing that this particular group could >> do to preempt it is to define an initial set of one-digit classes and an >> easy procedure for augmenting it. > I can't quite tell whether you're proposing that we start with > something we're going to build, but make one taxonomy; or whether > you're suggesting we standardize a procedure for augmenting a base set > of classes. The thing that worries me about the latter suggestion is > that we'll end up with classification schemes that are local only: > everyone will have their pet classes. Since we're supposed to be > about interoperability at the IETF, it seems to me that it would be > better to have some proposal that converges on a single taxonomy. > > In any case, given that the IETF doesn't attract taxonomic expertise > the way other SDOs do, it seems to me it would be better to adopt some > external classification as the basis for work than to go off and make > our own. I'm particularly concerned with suggestions like this: > >> The initial classification should be very simple and obvious. > Obvious to one person is obscure to another. The example you gave was > to me much less compelling than some other classes with which I'd > naturally divide up the universe, and I think we could spend a long > time arguing about which "obvious" classification was the one true > one. Andrew, The concern is understandable, and there are proprietary products placing domains into specific categories. The overall number of categories normally does not exceed an ability to list "all that apply" as bit flags within a small data block. Depending upon the protocol involved, these bit definitions change. For email, some customers base acceptance upon the geo-location of the source. Some base this on associated AS values deduced through resolution of servers. Some increase filtering thresholds when the domain is being spoofed, which often occurs with online financial related transactions. One might imagine wanting recognition of government related sources, but access to these domains normally are controlled and are already distinct. There are likely a number of third-party service categories that should be handled differently, type of authentications used, languages, etcetera, that will improve email's integrity when categorized. Acceptance based upon categories of businesses that some might view negatively, but that have little bearing upon behavior or importance, would only further Balkanize email. Categorization for its own sake should be discouraged. "It might be nice to know" does not offer suitable justification in the creation and support of a standardized category, especially when attempting to offer as much actionable information as possible within a single frame. Categories should not be offered that might otherwise obscure a domain's merits. -Doug From stephen.farrell@cs.tcd.ie Mon Aug 16 17:07: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 9AE653A6805 for ; Mon, 16 Aug 2010 17:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.768 X-Spam-Level: X-Spam-Status: No, score=-102.768 tagged_above=-999 required=5 tests=[AWL=-0.169, 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 0v+q3lMWjfE0 for ; Mon, 16 Aug 2010 17:07:30 -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 106703A67E7 for ; Mon, 16 Aug 2010 17:07:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 663933E4085; Tue, 17 Aug 2010 01:08:04 +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=1282003684; bh=qzFdsY9nf9asYQ 3tJGE3SmBHbQf3BO/kya3pfwzXrtk=; b=K0J86gNmhPLcFPDhSxR6AAkSAxnA7p eojoVtN3+GULU8cp5uYhRlw3CKBQ4z6LjnnA904wX9JegyZTEz4UxpBaMwWrLfkL mu4PYWnxuqww2ledmU3HVKRKyx2JdqO87ZfIL1ftBk8zHrv6FtYlFGR6f6M4RUpP QbPL44RjI7VmaUxTLqibL7qxTvyrKRF+/AbLyeaKP6aVK/iTQ/8CwPAoPJif4rgS HZ7nzQayiv5D4vGK8vqEu4yIbsBikz0j5FPNOob/Y5Is20banVZD8AhS62rkLqgf RlQkFQiCB9G2L19LajaI8x4wzcejY+8ZdOmjFPiTRC1zQ6kkwijwU75Q== 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 4+m1hYN4K4qp; Tue, 17 Aug 2010 01:08:04 +0100 (IST) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id C27123E4083; Tue, 17 Aug 2010 01:08:03 +0100 (IST) Message-ID: <4C69D2E1.1080904@cs.tcd.ie> Date: Tue, 17 Aug 2010 01:08:01 +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: "J.D. Falk" References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <83FF4685-3C5B-425E-8516-081698B5BD5C@cybernothing.org> In-Reply-To: <83FF4685-3C5B-425E-8516-081698B5BD5C@cybernothing.org> 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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 00:07:31 -0000 On 17/08/10 00:29, J.D. Falk wrote: > Speaking as co-chair, for whatever weight that may carry on a pre-WG mailing list.... > > On Aug 16, 2010, at 3:20 AM, Stephen Farrell wrote: > >> I think Murray's suggestion (make NAICS some kind of tagged option) >> caters for this. If folks play with NAICS but then need something >> else then they can do that. Personally, I don't think these industrial >> classifications will useful for very long, but I guess so long as >> we can change, there's no harm in trying. > > It's hard to argue against the need for standard classifications, and even harder to argue against the need to change or update those classifications as our needs evolve. > > But as we've already seen on this list, different people have very different criteria for differentiation of mail streams. We could very easily end up arguing about definitions for decades without ever reaching a single taxonomy that'll work for everyone. > > So I'd like to expand from Murray's original suggestion, and ask if we could please agree that: Almost. My quibbles below. :-) > 1. the ability to reference a standard taxonomy of sender types is worthy of further discussion, and s/sender types/foo/ where foo are the things about which reputation is asserted (domains, addresses, BSSIDs, whatever we end up with there, maybe including mail senders,/authors/..., but equally maybe just domains). and s/a standard taxonomy/one or more standard taxonomies/ > 2. the specific contents of said taxonomy are out of scope for this group. I think maybe the management of other taxonomies is almost always out of scope, (other than to react to someone else's change control), but any taxonomy that'd be useful needs to be encoded/tagged, which latter part would have to be in scope. The "almost always" above, is because it could be that there is some Internet specific taxonomy that would end up in scope (e.g. "talks RFCxxxx" if that were useful). But I'm not making any suggestions there now, 'cause I've not got (or heard) any good ideas:-) S. > > If there's a strong desire for an IETF effort to create such a taxonomy, perhaps a separate (but obviously complimentary) effort could be spun up. However, I don't think the domainrep effort has to wait for it. > > Any strong opposition? Does this need a formal call for consensus? > > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep > From macfisherman@gmail.com Tue Aug 17 07:24: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 95C1F3A659B for ; Tue, 17 Aug 2010 07:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.021 X-Spam-Level: X-Spam-Status: No, score=-4.021 tagged_above=-999 required=5 tests=[AWL=-1.422, 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 0mRrh2WByFqm for ; Tue, 17 Aug 2010 07:24:17 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 927013A688F for ; Tue, 17 Aug 2010 07:24:17 -0700 (PDT) Received: by qyk9 with SMTP id 9so3549164qyk.10 for ; Tue, 17 Aug 2010 07:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=Q+remYTAVVuXe+8KsIr3mITGxds8hkJAuKUrMVj1ez0=; b=Y/dNC2B9T4G51rBDEf+JNbr2h3nFnkZerEkwyHRTHEvuSNjAlE10YrOCbN5tJPgT1C X6MRDZawRJQuMESRfQVz4TmkW/Y6VrbiGAc8Ohdn1Z89xNYv+POMACgNYfDyQaZYtyT0 fpWjdxOPD8UGk0m0xcLXl0kwO9WqjCia2lU5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=hcAYCYs+ihHNC57+XCRrajfwLP8905tVTwVL+j1dTS6ty9yHJskBrD3PapA0MwqXGs qfwbUHpgM0AlUcokn0yTRoe5QAJBGMYIrtcjaX4+oolff66Zn5n1Dfedb2Ur2QaFdk2l OH5hyiAB5IPXzxuc8FRLim55QDY4tqYee5rh8= MIME-Version: 1.0 Received: by 10.224.3.3 with SMTP id 3mr4390690qal.33.1282055092850; Tue, 17 Aug 2010 07:24:52 -0700 (PDT) Received: by 10.229.28.129 with HTTP; Tue, 17 Aug 2010 07:24:52 -0700 (PDT) In-Reply-To: <20100816231607.29638.qmail@joyce.lan> References: <20100816215255.GB86057@shinkuro.com> <20100816231607.29638.qmail@joyce.lan> Date: Tue, 17 Aug 2010 10:24:52 -0400 Message-ID: From: Jeff Macdonald To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 14:24:18 -0000 On Mon, Aug 16, 2010 at 7:16 PM, John Levine wrote: >>> The initial classification should be very simple and obvious. > > At DAC, when we were working on VBR, at one point we had a detailed > taxonomy of mail types, based on the extensive experience of everyone > involved, and we ended up throwing everything out other than mailing > list, because it wasn't clear to anyone that the taxonomy solved any > problems. > > I'm pretty sure that a reputation system that told me whether a sender > was a bank or a government would be useful. =A0I'm pretty sure that the > distinction between a camel farmer and a pig farmer is not. =A0Between > that I'm not sure. =A0This tells me that we need a place holder, and we > can worry about the details when we have more experience and more > comments from people who run real mail systems. Could it be simplified for all use cases (meaning email and other protocols) to simply say "high value" and "low value"? --=20 Jeff Macdonald Ayer, MA From ajs@shinkuro.com Tue Aug 17 07:57:17 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 D831A3A697B for ; Tue, 17 Aug 2010 07:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.589 X-Spam-Level: X-Spam-Status: No, score=-101.589 tagged_above=-999 required=5 tests=[AWL=1.010, 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 cEYgUgq0PLYb for ; Tue, 17 Aug 2010 07:57:17 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 122FE3A6848 for ; Tue, 17 Aug 2010 07:57: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 E7D8B1ECB408 for ; Tue, 17 Aug 2010 14:57:51 +0000 (UTC) Date: Tue, 17 Aug 2010 10:57:50 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100817145750.GC88824@shinkuro.com> References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C69CF37.6060608@mail-abuse.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 14:57:17 -0000 On Mon, Aug 16, 2010 at 04:52:23PM -0700, Douglas Otis wrote: > > The concern is understandable, and there are proprietary products > placing domains into specific categories. [other examples elided] I can't tell if you're arguing that local evaluation is necessary, and that therefore a single taxonomy won't work; or if you're arguing instead along with me that balkanizing the categorization would be bad. Which were you intending? > Categorization for its own sake should be discouraged. "It might be > nice to know" does not offer suitable justification in the creation and > support of a standardized category, I don't think anyone was arguing that way. I think the argument was instead that (1) there appears to be a need for categories; (2) we don't have taxonometric expertise just clamouring to help out here; (3) there are existing taxonomies to be employed. If you are arguing that (1) is false, then I don't understand the argument yet. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From johnl@iecc.com Tue Aug 17 10:17: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 C603F3A63C9 for ; Tue, 17 Aug 2010 10:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.974 X-Spam-Level: X-Spam-Status: No, score=-109.974 tagged_above=-999 required=5 tests=[AWL=1.224, 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 uOYa4ZWg+Vbx for ; Tue, 17 Aug 2010 10:17:31 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 116FF3A67C2 for ; Tue, 17 Aug 2010 10:17:30 -0700 (PDT) Received: (qmail 93985 invoked from network); 17 Aug 2010 17:18:05 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 17 Aug 2010 17:18:05 -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=k1008; olt=johnl@user.iecc.com; bh=MFUoBNKsh9KFLYNiY4uFqTvhhDCtmYfp+T4oFBg7Uh0=; b=VbMPEnVrGcufTcxGwt05C4E0dViyhkcDkEOCNu9UGnfotCpDwry1kuRGF4ILehe2bnKCkSuOc1oATnoSBrCAz4iFdc5xmE3HRG/mn7ln+mIDsoYZIo2x//Nfq5aRuMhaHDh8SrL1qs2pIqKxCzIyOSX4YXbPvab8sWGe3L3cTT8= Date: 17 Aug 2010 17:18:05 -0000 Message-ID: <20100817171805.92024.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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 17:17:32 -0000 >Could it be simplified for all use cases (meaning email and other >protocols) to simply say "high value" and "low value"? No, it's orthogonal. I want to be able to publish reputation scores that say, in effect, "this is spam, but it really is from Bank of America." A few months ago I got some mortgage spam to an address that only appears on spam lists, with a valid BofA DKIM signature. I treat that differently from mail that purports to be from BofA but is actually a phish. R's, John From ajs@shinkuro.com Tue Aug 17 11:10:22 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 AC13F3A6901 for ; Tue, 17 Aug 2010 11:09:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 f5z6PlbmJgz3 for ; Tue, 17 Aug 2010 11:09:48 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 08C4E3A6880 for ; Tue, 17 Aug 2010 11:09:30 -0700 (PDT) Received: from crankycanuck.ca (CPE002127da73a9-CM00195eefd958.cpe.net.cable.rogers.com [99.255.2.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 74A891ECB408 for ; Tue, 17 Aug 2010 18:09:23 +0000 (UTC) Date: Tue, 17 Aug 2010 14:09:07 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100817180907.GB89449@shinkuro.com> References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <83FF4685-3C5B-425E-8516-081698B5BD5C@cybernothing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83FF4685-3C5B-425E-8516-081698B5BD5C@cybernothing.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 18:10:22 -0000 On Mon, Aug 16, 2010 at 04:29:53PM -0700, J.D. Falk wrote: t: > > 1. the ability to reference a standard taxonomy of sender types is worthy of further discussion, and > 2. the specific contents of said taxonomy are out of scope for this group. I can support that. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From macfisherman@gmail.com Tue Aug 17 12:20: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 534683A68CD for ; Tue, 17 Aug 2010 12:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.912 X-Spam-Level: X-Spam-Status: No, score=-3.912 tagged_above=-999 required=5 tests=[AWL=-1.313, 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 4GHieifGwWH6 for ; Tue, 17 Aug 2010 12:20:21 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 6455F3A6804 for ; Tue, 17 Aug 2010 12:20:21 -0700 (PDT) Received: by qyk1 with SMTP id 1so994686qyk.10 for ; Tue, 17 Aug 2010 12:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/r+1rITrVXA4zsVbLNtO+xUxEk/FcQxG9mKlKjtK6IA=; b=iC2NJbgYwCHptpoa5p1JRmCkajq0vEBkdWI3DWOtW1sP1U1B01rmtm9FI85vrxR8IP jlLiUcEyE9dydHhVjcIB010niwiFLemvkdv83POobydxzmOT4s2+RS9y4hxmFGZ9n45F rCMlO8LMCW9Yvz1wz9SOsX8V+xGW5U1uI0jZc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hwZP3zo0aUktlVTLyxEH3wEO9zCPKw4aH6KvnS4CH7OX5EzWUXfbrdWdNgNzIyePeR 4zDSwDP33NPvHfMN9A8d5jqKGcanhr2+Rc8uJCAIhPCSOJg8smrd+40dGwdTgP2O3UQp 1i9oWPrbSp6cNwv0t9r5/5lmrNg/cxKdIi8qw= MIME-Version: 1.0 Received: by 10.229.229.70 with SMTP id jh6mr5111201qcb.161.1282072856634; Tue, 17 Aug 2010 12:20:56 -0700 (PDT) Received: by 10.229.28.129 with HTTP; Tue, 17 Aug 2010 12:20:56 -0700 (PDT) In-Reply-To: <20100817171805.92024.qmail@joyce.lan> References: <20100817171805.92024.qmail@joyce.lan> Date: Tue, 17 Aug 2010 15:20:56 -0400 Message-ID: From: Jeff Macdonald To: John Levine Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 19:20:25 -0000 On Tue, Aug 17, 2010 at 1:18 PM, John Levine wrote: >>Could it be simplified for all use cases (meaning email and other >>protocols) to simply say "high value" and "low value"? > > No, it's orthogonal. But is it really? >=A0I want to be able to publish reputation scores > that say, in effect, "this is spam, but it really is from Bank of > America." yes, I understand that. But you could also say "this is spam, but it is from a high value domain." --=20 Jeff Macdonald Ayer, MA From dotis@mail-abuse.org Tue Aug 17 12:26: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 707B33A6901 for ; Tue, 17 Aug 2010 12:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.38 X-Spam-Level: X-Spam-Status: No, score=-105.38 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_20=-0.74, 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 JqDiP1Kw+L5K for ; Tue, 17 Aug 2010 12:26:28 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 2EF073A6889 for ; Tue, 17 Aug 2010 12:26:28 -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 AAFCFA94449 for ; Tue, 17 Aug 2010 19:26:57 +0000 (UTC) Message-ID: <4C6AE282.1070907@mail-abuse.org> Date: Tue, 17 Aug 2010 12:26:58 -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: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> In-Reply-To: <20100817145750.GC88824@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 19:26:29 -0000 On 8/17/10 7:57 AM, Andrew Sullivan wrote: > On Mon, Aug 16, 2010 at 04:52:23PM -0700, Douglas Otis wrote: > > The concern is understandable, and there are proprietary products > > placing domains into specific categories. > [other examples elided] > > I can't tell if you're arguing that local evaluation is necessary, > and that therefore a single taxonomy won't work; or if you're > arguing instead along with me that balkanizing the categorization > would be bad. Which were you intending? Indicating all possible categories of traffic emitted by a domain could prove beneficial. Using 6 decimal digits to indicate a category makes it impractical to identify all relevant categories within a single frame. Internally, we use about 60 different categories, where a domain often falls within several. The NAICS list is impractical for three reasons: 1) its enumeration is not suitable for category aggregation. 2) its categories are unrelated to Internet commerce. 3) its categories don't map into specific handling considerations. > > Categorization for its own sake should be discouraged. "It might > > be nice to know" does not offer suitable justification in the > > creation and support of a standardized category, > > I don't think anyone was arguing that way. I think the argument was > instead that (1) there appears to be a need for categories; (2) we > don't have taxonometric expertise just clamouring to help out here; > (3) there are existing taxonomies to be employed. If you are > arguing that (1) is false, then I don't understand the argument yet. Again, government categorization of business endeavors offers virtually nothing about undesired behavior, or whether they conduct sensitive online transactions in a specific manner. In other words, a breakdown of behaviors, and general obligations would prove more useful, since this could then map into specific handling, such as should TLS certificates verify its emitting servers? With respect to online transactions, what is gained by a reputation server claiming an entity represents an acquiring bank, without specific types of direct authentication being the basis of the assertion? Does the IETF desire a protocol for Dun and Bradstreet, infoGROUP, Moody's, etc.? Even one of these companies would unlikely be able to offer suitable categories for the 200 million companies covered, when not paying specific attention to online behaviors. Unfortunately, most of the specifically relevant categories would relate to undesired behaviors. - network scanning - spamming - malware distribution - phishing - denial of service attacks - fast-flux domain activity - compromised servers - open proxies - open relays With respect to email, some categories that would make sense is whether they verify subscriptions, honor unsubscribe requests, or send unsolicited messages. To bolster filtering efforts, some categories could indicate how a domain is authenticated. Such authentication advice would help counter phishing attempts within exchange sessions. So what is the reputation service attempting to provide: a) a D&B type of service, b) authentication advice, c) undesired behavior warnings. No single business category is immune from being compromised, or prevents organized crime from acquiring all the related infrastructure. In that regard, a category that indicates some entity purports to be an acquiring bank means what exactly? That it is therefore within the fellow-hood of man? Or that the reputation service is also liable for any subsequent domain related bank fraud? Beyond the single business category that John advocated, what metrics can a reputation service use? How should these metrics be listed? What would a 0 to 100 rating mean? Would 0 or 49 mean "unknown", or does 0 mean "untouchable"? What would a 0 to 100 certainty mean? Would 0 mean "don't know" because it is new, or that 0 is due to a recent change in status? Much of our information goes back many years, and yet some advocated only considering information within the last 6 months with respect to IP addresses. Should the same short-term view persist with domains as well? Should the reputation service indicate the duration of its information, or that of the domain, or which ever is shorter? -Doug From johnl@iecc.com Tue Aug 17 12:28: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 2EC3B3A6853 for ; Tue, 17 Aug 2010 12:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.979 X-Spam-Level: X-Spam-Status: No, score=-110.979 tagged_above=-999 required=5 tests=[AWL=2.220, BAYES_00=-2.599, GB_I_LETTER=-2, 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 yOiS4+5KZnM4 for ; Tue, 17 Aug 2010 12:28:17 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id D5BD43A6804 for ; Tue, 17 Aug 2010 12:28:12 -0700 (PDT) Received: (qmail 53581 invoked from network); 17 Aug 2010 19:28:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=R0lQ38uflY8VQGKdAyP9UZz4kpMtDPt33Rxc7PiR060=; b=1efuSe/gVYWynavBjtWK+qFCqe9PCzpnXxQBDVOjPVNamVNTOCCCGdqQ0X3YZFPRK4IoI56jCW4CCd1MCeXHiBsrzWrZp7e1gJf7N3Gi1N1cs48x7w5CWHJpCLhNewW8ovKIe8HLoDSk6P19nL49Amc3Nz9lerbvHQDxWX+ucrc= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 17 Aug 2010 19:28:25 -0000 Date: 17 Aug 2010 15:28:47 -0400 Message-ID: From: "John R. Levine" To: "Jeff Macdonald" In-Reply-To: References: <20100817171805.92024.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="3825401791-213785198-1282073327=:19100" Cc: domainrep@ietf.org Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 19:28:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-213785198-1282073327=:19100 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE >> =A0I want to be able to publish reputation scores >> that say, in effect, "this is spam, but it really is from Bank of >> America." > > yes, I understand that. But you could also say "this is spam, but it > is from a high value domain." You could, but now you have yet another level of indirection, in which you= =20 have to decide whether you agree with my opinion of what is high value and= =20 what isn't. Personally, I think that mail from swine farms is very high=20 value*, but mail from cameloid farms is down there with newsletters from=20 electronics retailers. R's, John * - see http://www.thepiggery.net --3825401791-213785198-1282073327=:19100-- From ajs@shinkuro.com Tue Aug 17 12:55: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 AB3453A6868 for ; Tue, 17 Aug 2010 12:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.606 X-Spam-Level: X-Spam-Status: No, score=-101.606 tagged_above=-999 required=5 tests=[AWL=0.993, 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 FBxLeIX6Gv0N for ; Tue, 17 Aug 2010 12:55:19 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 7EFEC3A6859 for ; Tue, 17 Aug 2010 12:55:19 -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 44DD51ECB408 for ; Tue, 17 Aug 2010 19:55:54 +0000 (UTC) Date: Tue, 17 Aug 2010 15:55:52 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100817195552.GB89703@shinkuro.com> References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6AE282.1070907@mail-abuse.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 19:55:20 -0000 On Tue, Aug 17, 2010 at 12:26:58PM -0700, Douglas Otis wrote: > > So what is the reputation service attempting to provide: > a) a D&B type of service, > b) authentication advice, > c) undesired behavior warnings. I think this is at least the good beginning of the problem statement for this approach. Do we have an answer? > In that regard, a category that indicates some entity purports to be an > acquiring bank means what exactly? Well, wait a minute. I thought the point of this was to have a "purports to be" statement, and then a reputation service that rates that claim according to some reputation-service-proprietary rating rules. Maybe I have the model completely wrong? (Feel free to hit me with the relevant clue by four.) It sounds to me like most of the questions you're asking are on the line of, "How should a reputation-ranker _use_ this data?" which is (to me) not part of the remit here. If that's what we're supposed to be working on, then I don't think this is work that even remotely belongs in the IETF. That's not a protocol, and there's no test of interoperation except "same result," which doesn't even need a protocol. > Beyond the single business category that John advocated, what metrics > can a reputation service use? How should these metrics be listed? This sounds to me like an operational question. See above. > Much of our information goes back many years, and yet some advocated > only considering information within the last 6 months with respect to IP > addresses. Should the same short-term view persist with domains as > well? Should the reputation service indicate the duration of its > information, or that of the domain, or which ever is shorter? Same again. To begin with, it surely depends on what the history of the domain itself is. If it was created 10 minutes ago but happens to be spelled "mitre.org", you might have reason to be suspicious (FWIW, I believe that mitre.org is actually the oldest domain in the .org registry, and whois tells me it was created in 1985). A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From msk@cloudmark.com Tue Aug 17 14:25: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 BF4923A684B for ; Tue, 17 Aug 2010 14:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.362 X-Spam-Level: X-Spam-Status: No, score=-103.362 tagged_above=-999 required=5 tests=[AWL=-0.763, 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 BZfjAVc7N09B for ; Tue, 17 Aug 2010 14:25:47 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id E41523A6838 for ; Tue, 17 Aug 2010 14:25:47 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 17 Aug 2010 14:26:23 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 17 Aug 2010 14:26:22 -0700 Thread-Topic: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) Thread-Index: Acs+RjXmFwF4e+L3Sn2kjkWHdUhwvQADAJog Message-ID: References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> In-Reply-To: <20100817195552.GB89703@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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 21:25:48 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Tuesday, August 17, 2010 12:56 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A > sketch of a small query reputation system) >=20 > On Tue, Aug 17, 2010 at 12:26:58PM -0700, Douglas Otis wrote: > > > > So what is the reputation service attempting to provide: > > a) a D&B type of service, > > b) authentication advice, > > c) undesired behavior warnings. >=20 > I think this is at least the good beginning of the problem statement > for this approach. Do we have an answer? Do we have to pick one of those? I'm not sure that a protocol specification, which I imagine will be the fir= st output of this group, needs to specify any of that. I suspect we're jus= t going to define a language for making the query and getting the answer. = It would be up to the consumer of the data to decide how to use it, partly = based on the goals of the consumer and partly from some a priori knowledge = of who's providing the data and what that agency tells you about how the da= ta are prepared. > Well, wait a minute. I thought the point of this was to have a > "purports to be" statement, and then a reputation service that rates > that claim according to some reputation-service-proprietary rating > rules. Maybe I have the model completely wrong? (Feel free to hit me > with the relevant clue by four.) It sounds to me like most of the > questions you're asking are on the line of, "How should a > reputation-ranker _use_ this data?" which is (to me) not part of the > remit here. If that's what we're supposed to be working on, then I > don't think this is work that even remotely belongs in the IETF. > That's not a protocol, and there's no test of interoperation except > "same result," which doesn't even need a protocol. I totally agree. I also think how a reputation provider goes about collect= ing and collating data to use as the report it returns in response to a que= ry is not something the IETF can specify. From msk@cloudmark.com Tue Aug 17 14:28:35 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 8404A3A6853 for ; Tue, 17 Aug 2010 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.355 X-Spam-Level: X-Spam-Status: No, score=-103.355 tagged_above=-999 required=5 tests=[AWL=-0.756, 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 CpdNrlGQRgCi for ; Tue, 17 Aug 2010 14:28:34 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id B50B13A684B for ; Tue, 17 Aug 2010 14:28:34 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 17 Aug 2010 14:29:10 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 17 Aug 2010 14:29:09 -0700 Thread-Topic: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) Thread-Index: Acs+RjXmFwF4e+L3Sn2kjkWHdUhwvQADAJogAAA1WAA= Message-ID: References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 21:28:35 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Murray S. Kucherawy > Sent: Tuesday, August 17, 2010 2:26 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A > sketch of a small query reputation system) >=20 > I totally agree. I also think how a reputation provider goes about > collecting and collating data to use as the report it returns in > response to a query is not something the IETF can specify. Also, if we're careful, we might be able to do this in a way that doesn't e= ven constrain use of such a protocol to domains. It could also be used for= URLs, IP addresses, restaurants, movies, or anything really. From ajs@shinkuro.com Tue Aug 17 14:46:00 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 0108C3A6838 for ; Tue, 17 Aug 2010 14:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.616 X-Spam-Level: X-Spam-Status: No, score=-101.616 tagged_above=-999 required=5 tests=[AWL=0.983, 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 75XypBdfLPKx for ; Tue, 17 Aug 2010 14:45:59 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 33DB63A67F6 for ; Tue, 17 Aug 2010 14:45:59 -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 0B6D11ECB408 for ; Tue, 17 Aug 2010 21:46:33 +0000 (UTC) Date: Tue, 17 Aug 2010 17:46:32 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100817214632.GP89703@shinkuro.com> References: <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 21:46:00 -0000 On Tue, Aug 17, 2010 at 02:26:22PM -0700, Murray S. Kucherawy wrote: > > > So what is the reputation service attempting to provide: > > > a) a D&B type of service, > > > b) authentication advice, > > > c) undesired behavior warnings. > > > > I think this is at least the good beginning of the problem statement > > for this approach. Do we have an answer? > > Do we have to pick one of those? No, I don't think so. But it'd be nice to understand what problems we _must_ solve, what problems we might happily solve if they're nearly free, and what problems are just out of scope. One of Doug's objections I find significant: the proposed taxonomy doesn't allow multiple categories, which could indeed be troublesome in cases where an operator has poor "domain hygeine". (Moreover, the temptation will be to solve this with "DNS tree climbing", which is ugly and which will also land us in the usual fight about whether that's legitimate. Given the difficulty of detecting zone cuts, I think it isn't.) Your downthread remark about specifying the _protocol_ correctly so that it is properly generic is, I think, still the right impulse. It's certainly what interests me. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From R.E.Sonneveld@sonnection.nl Tue Aug 17 14:56: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 640193A67F3 for ; Tue, 17 Aug 2010 14:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.773 X-Spam-Level: X-Spam-Status: No, score=-3.773 tagged_above=-999 required=5 tests=[AWL=-2.270, BAYES_00=-2.599, 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 nQvC83FR+VMb for ; Tue, 17 Aug 2010 14:56:47 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id 52B453A66B4 for ; Tue, 17 Aug 2010 14:56:46 -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 <0L7B00323GZK3600@lion.sonnection.nl> for domainrep@ietf.org; Tue, 17 Aug 2010 23:57:20 +0200 (CEST) Message-id: <4C6B05C0.7000405@sonnection.nl> Date: Tue, 17 Aug 2010 23:57:20 +0200 From: "Rolf E. Sonneveld" User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-version: 1.0 To: "Murray S. Kucherawy" References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> In-reply-to: Content-type: multipart/alternative; boundary=------------050203090207070001090707 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1282082240; bh=R3UAuNFrjuJCnb+o1dis/ZCLWLUTTLcpm5nLIJW5rpQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=eu5jmEyEfjHAsFUVZnuw9VhLO1RZikCpH9FNcJ//HI6uHMvom/LRd2sz08AXf2FUi 8XMaL2QMVGSpjJtvysCQH7jYgFYrP4TcVBhvcfGMKJtr0XMF/hDTeQzXOObQjTuiK2 XLnLy1pwqFoipoFSFLN1cehpJOaMvgHSUNE8lM3A= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7B00323GZK3600 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 21:56:48 -0000 This is a multi-part message in MIME format. --------------050203090207070001090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On >> Behalf Of Andrew Sullivan >> Sent: Tuesday, August 17, 2010 12:56 PM >> To: domainrep@ietf.org >> Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A >> sketch of a small query reputation system) >> >> On Tue, Aug 17, 2010 at 12:26:58PM -0700, Douglas Otis wrote: >> >>> So what is the reputation service attempting to provide: >>> a) a D&B type of service, >>> b) authentication advice, >>> c) undesired behavior warnings. >>> >> I think this is at least the good beginning of the problem statement >> for this approach. Do we have an answer? >> > > Do we have to pick one of those? > > I'm not sure that a protocol specification, which I imagine will be the first output of this group, needs to specify any of that. I suspect we're just going to define a language for making the query and getting the answer. It would be up to the consumer of the data to decide how to use it, partly based on the goals of the consumer and partly from some a priori knowledge of who's providing the data and what that agency tells you about how the data are prepared. > > >> Well, wait a minute. I thought the point of this was to have a >> "purports to be" statement, and then a reputation service that rates >> that claim according to some reputation-service-proprietary rating >> rules. Maybe I have the model completely wrong? (Feel free to hit me >> with the relevant clue by four.) It sounds to me like most of the >> questions you're asking are on the line of, "How should a >> reputation-ranker _use_ this data?" which is (to me) not part of the >> remit here. If that's what we're supposed to be working on, then I >> don't think this is work that even remotely belongs in the IETF. >> That's not a protocol, and there's no test of interoperation except >> "same result," which doesn't even need a protocol. >> > > I totally agree. I also think how a reputation provider goes about collecting and collating data to use as the report it returns in response to a query is not something the IETF can specify. > +1 Nonetheless, I think I understand why Doug comes up with these questions: we're trying to define a language/protocol to query reputation data, without exactly knowing what that data will look like, what elements it will contain. Is it a simple score, or will it be a complex reputation field with multiple elements? I have seen various elements coming along on this list, proposed by various people, like: * Quality of domain * Confidence of opinion * NAICS code or similar code set * Type- or context specific data (web/mail etc.) * Generic reputations with details about the kinds of negative information they're based on * Recency of the bad events * (did I forget something?) Is it possible, without definining the reputation system itself, to define what data we'll have to query? Or is one without the other a mission impossible? I propose to try to first define a highlevel design, without going into the details (goats and pigs etc.) too much. So the question is, what would constitute to this high level design? What (other, not yet mentioned) characteristics of the reputation data? /rolf --------------050203090207070001090707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Murray S. Kucherawy wrote: 
-----Original Message-----
From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On
Behalf Of Andrew Sullivan
Sent: Tuesday, August 17, 2010 12:56 PM
To: domainrep@ietf.org
Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A
sketch of a small query reputation system)

On Tue, Aug 17, 2010 at 12:26:58PM -0700, Douglas Otis wrote:
    
So what is the reputation service attempting to provide:
 a) a D&B type of service,
 b) authentication advice,
 c) undesired behavior warnings.
      
I think this is at least the good beginning of the problem statement
for this approach.  Do we have an answer?
    

Do we have to pick one of those?

I'm not sure that a protocol specification, which I imagine will be the first output of this group, needs to specify any of that.  I suspect we're just going to define a language for making the query and getting the answer.  It would be up to the consumer of the data to decide how to use it, partly based on the goals of the consumer and partly from some a priori knowledge of who's providing the data and what that agency tells you about how the data are prepared.

  
Well, wait a minute.  I thought the point of this was to have a
"purports to be" statement, and then a reputation service that rates
that claim according to some reputation-service-proprietary rating
rules.  Maybe I have the model completely wrong?  (Feel free to hit me
with the relevant clue by four.)  It sounds to me like most of the
questions you're asking are on the line of, "How should a
reputation-ranker _use_ this data?" which is (to me) not part of the
remit here.  If that's what we're supposed to be working on, then I
don't think this is work that even remotely belongs in the IETF.
That's not a protocol, and there's no test of interoperation except
"same result," which doesn't even need a protocol.
    

I totally agree.  I also think how a reputation provider goes about collecting and collating data to use as the report it returns in response to a query is not something the IETF can specify.

+1

Nonetheless, I think I understand why Doug comes up with these questions: we're trying to define a language/protocol to query reputation data, without exactly knowing what that data will look like, what elements it will contain. Is it a simple score, or will it be a complex reputation field with multiple elements? I have seen various elements coming along on this list, proposed by various people, like:

  • Quality of domain
  • Confidence of opinion
  • NAICS code or similar code set
  • Type- or context specific data (web/mail etc.)
  • Generic reputations with details about the kinds of negative information they're based on
  • Recency of the bad events
  • (did I forget something?)
Is it possible, without definining the reputation system itself, to define what data we'll have to query? Or is one without the other a mission impossible? I propose to try to first define a highlevel design, without going into the details (goats and pigs etc.) too much. So the question is, what would constitute to this high level design? What (other, not yet mentioned) characteristics of the reputation data?

/rolf

--------------050203090207070001090707-- From msk@cloudmark.com Tue Aug 17 15:10: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 1C3363A68A2 for ; Tue, 17 Aug 2010 15:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.347 X-Spam-Level: X-Spam-Status: No, score=-103.347 tagged_above=-999 required=5 tests=[AWL=-0.749, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zd2qCk8-VTfg for ; Tue, 17 Aug 2010 15:10:29 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 3A2DF3A6869 for ; Tue, 17 Aug 2010 15:09:44 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 17 Aug 2010 15:10:13 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 17 Aug 2010 15:10:12 -0700 Thread-Topic: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) Thread-Index: Acs+VyxSF/tmEXgxRyS3TsYBudd/KgAAXKJw Message-ID: References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> <4C6B05C0.7000405@sonnection.nl> In-Reply-To: <4C6B05C0.7000405@sonnection.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB012BD379D7B046ABE1472D8093C61C01F8F0BE88EXCHC2corpclo_" MIME-Version: 1.0 Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 17 Aug 2010 22:10:39 -0000 --_000_BB012BD379D7B046ABE1472D8093C61C01F8F0BE88EXCHC2corpclo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, DKIM for example defined a general "tag=3Dvalue" syntax, then declare= d set of tags it supports (some mandatory, some optional), and then further= specified that unknown tags must be ignored. Maybe a protocol defined her= e specifies a general syntax and a minimum set of known parameters (e.g. "r= =3D" for the reputation and "c=3D" for the confidence) and then the rest ar= e either processed or ignored based on what the client knows about the data= the server will return. It's nice and extensible, provides a minimum impl= ementation set, and is fairly easy to parse. Maybe an IANA registry of tags and their legal values and semantics? From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl] Sent: Tuesday, August 17, 2010 2:57 PM To: Murray S. Kucherawy Cc: domainrep@ietf.org Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketc= h of a small query reputation system) Murray S. Kucherawy wrote: -----Original Message----- From: domainrep-bounces@ietf.org [mailto= :domainrep-bounces@ietf.org] On Behalf Of Andrew Sullivan Sent: Tuesday, August 17, 2010 12:56 PM To: domainrep@ietf.org Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) On Tue, Aug 17, 2010 at 12:26:58PM -0700, Douglas Otis wrote: So what is the reputation service attempting to provide: a) a D&B type of service, b) authentication advice, c) undesired behavior warnings. I think this is at least the good beginning of the problem statement for this approach. Do we have an answer? Do we have to pick one of those? I'm not sure that a protocol specification, which I imagine will be the fir= st output of this group, needs to specify any of that. I suspect we're jus= t going to define a language for making the query and getting the answer. = It would be up to the consumer of the data to decide how to use it, partly = based on the goals of the consumer and partly from some a priori knowledge = of who's providing the data and what that agency tells you about how the da= ta are prepared. Well, wait a minute. I thought the point of this was to have a "purports to be" statement, and then a reputation service that rates that claim according to some reputation-service-proprietary rating rules. Maybe I have the model completely wrong? (Feel free to hit me with the relevant clue by four.) It sounds to me like most of the questions you're asking are on the line of, "How should a reputation-ranker _use_ this data?" which is (to me) not part of the remit here. If that's what we're supposed to be working on, then I don't think this is work that even remotely belongs in the IETF. That's not a protocol, and there's no test of interoperation except "same result," which doesn't even need a protocol. I totally agree. I also think how a reputation provider goes about collect= ing and collating data to use as the report it returns in response to a que= ry is not something the IETF can specify. +1 Nonetheless, I think I understand why Doug comes up with these questions: w= e're trying to define a language/protocol to query reputation data, without= exactly knowing what that data will look like, what elements it will conta= in. Is it a simple score, or will it be a complex reputation field with mul= tiple elements? I have seen various elements coming along on this list, pro= posed by various people, like: * Quality of domain * Confidence of opinion * NAICS code or similar code set * Type- or context specific data (web/mail etc.) * Generic reputations with details about the kinds of negative informati= on they're based on * Recency of the bad events * (did I forget something?) Is it possible, without definining the reputation system itself, to define = what data we'll have to query? Or is one without the other a mission imposs= ible? I propose to try to first define a highlevel design, without going in= to the details (goats and pigs etc.) too much. So the question is, what wou= ld constitute to this high level design? What (other, not yet mentioned) ch= aracteristics of the reputation data? /rolf --_000_BB012BD379D7B046ABE1472D8093C61C01F8F0BE88EXCHC2corpclo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, DKIM for example defined a general “tag=3Dvalue&= #8221; syntax, then declared set of tags it supports (some mandatory, some optional), and then further specified that unknown tags must be ignored.  Maybe a protocol= defined here specifies a general syntax and a minimum set of known parameters (e.g.= “r=3D” for the reputation and “c=3D” for the confidence) and then the = rest are either processed or ignored based on what the client knows about the data the serv= er will return.  It’s nice and extensible, provides a minimum imple= mentation set, and is fairly easy to parse.

 

Maybe an IANA registry of tags and their legal values and semantics?

 

From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl]
Sent: Tuesday, August 17, 2010 2:57 PM
To: Murray S. Kucherawy
Cc: domainrep@ietf.org
Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: = A sketch of a small query reputation system)

 

Murray S. Kucherawy wrote: 

-----Origin=
al Message-----
From: domainrep-bounces@ietf.org [=
mailto:domainrep-bounces@ietf.or=
g] On
Behalf Of Andrew Sullivan
Sent: Tuesday, August 17, 2010 12:56 PM
To: domainrep@ietf.org
<= pre>Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A
sketch of a small query reputation system)
 
On Tue, Aug 17, 2010 at 12:26:58PM -07=
00, Douglas Otis wrote:
    =




So what is =
the reputation service attempting to provide:
 a) a D&=
amp;B type of service,
 b) authentication advice,=

 c) undesired behavior warnings.
&nbs=
p;     



I think this is at least the good beginning of the problem statement
for this approach.  Do we have an answer?
    
 
Do we have to pick one of those?
 
I'm not sure that a protocol specif=
ication, which I imagine will be the first output of this group, needs to s=
pecify any of that.  I suspect we're just going to define a language f=
or making the query and getting the answer.  It would be up to the con=
sumer of the data to decide how to use it, partly based on the goals of the=
 consumer and partly from some a priori knowledge of who's providing the da=
ta and what that agency tells you about how the data are prepared.
 
  
Well, wait =
a minute.  I thought the point of this was to have a
<= pre>"purports to be" statement, and then a reputation service tha= t rates
that claim according to some reputation-servic=
e-proprietary rating
rules.  Maybe I have the mod=
el completely wrong?  (Feel free to hit me
with t=
he relevant clue by four.)  It sounds to me like most of the
questions you're asking are on the line of, "How should a<=
o:p>
reputation-ranker _use_ this data?" which is (to =
me) not part of the
remit here.  If that's what w=
e're supposed to be working on, then I
don't think thi=
s is work that even remotely belongs in the IETF.
That=
's not a protocol, and there's no test of interoperation except<=
/pre>
"same result," which doesn't even need a protocol.=

    
 
I totally agree.  I also think how a =
reputation provider goes about collecting and collating data to use as the =
report it returns in response to a query is not something the IETF can spec=
ify.
 


+1

Nonetheless, I think I understand why Doug comes up with these questions: w= e're trying to define a language/protocol to query reputation data, without exac= tly knowing what that data will look like, what elements it will contain. Is it= a simple score, or will it be a complex reputation field with multiple elemen= ts? I have seen various elements coming along on this list, proposed by various people, like:

  • Quality of domain
  • Confidence of opinion
  • NAICS code or similar code set
  • Type- or context specific data (web/mail etc.= )
  • Generic reputations with details about the ki= nds of negative information they're based on
  • Recency of the bad events
  • (did I forget something?)

Is it possible, without definining the reputation system itself, to define what data we'll have to query? Or is one without the other a mission impossible? I propose to try t= o first define a highlevel design, without going into the details (goats and = pigs etc.) too much. So the question is, what would constitute to this high leve= l design? What (other, not yet mentioned) characteristics of the reputation d= ata?

/rolf

--_000_BB012BD379D7B046ABE1472D8093C61C01F8F0BE88EXCHC2corpclo_-- From dotis@mail-abuse.org Tue Aug 17 17:14: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 2848E3A6833 for ; Tue, 17 Aug 2010 17:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.124 X-Spam-Level: X-Spam-Status: No, score=-106.124 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, 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 UM1KoWp69lIU for ; Tue, 17 Aug 2010 17:14: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 112523A6827 for ; Tue, 17 Aug 2010 17:14: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 CD9F7A944C9 for ; Wed, 18 Aug 2010 00:14:58 +0000 (UTC) Message-ID: <4C6B2603.4020305@mail-abuse.org> Date: Tue, 17 Aug 2010 17:14:59 -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: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> <4C6B05C0.7000405@sonnection.nl> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 00:14:31 -0000 On 8/17/10 3:10 PM, Murray S. Kucherawy wrote: > > Well, DKIM for example defined a general “tag=value” syntax, then > declared set of tags it supports (some mandatory, some optional), and > then further specified that unknown tags must be ignored. Maybe a > protocol defined here specifies a general syntax and a minimum set of > known parameters (e.g. “r=” for the reputation and “c=” for the > confidence) and then the rest are either processed or ignored based > on what the client knows about the data the server will return. It’s > nice and extensible, provides a minimum implementation set, and is > fairly easy to parse. > > Maybe an IANA registry of tags and their legal values and semantics? This approach would not be practical for many protocols. The Google Safe Browser API offers a working example of an open reputation service currently being used by millions of browsers that does not leak client information. http://code.google.com/apis/safebrowsing/developers_guide_v2.html The domain's status depends upon which list contains a hash of the canonicalized URI. Clearly, the type of protocol specific exchanges being protected, dramatically impacts the general structure of the service. A quibble about how reputation should be generated and applied. You seem to envision a service that offers a complex function of reputation and confidence values, without offering specifics of how this information is applied. Clearly, the resulting uncertainty absolves the service of subsequent decisions. Such absolution is needed when the basis for reputation fails to authenticate the source, but is based upon an assumed source. Unfortunately, assumptions regarding the source of a message in the generation of reputation is inherently unfair, and is not something the IETF should promote. John gave a recent example of spamming attributed to BofA based upon their DKIM signature. Unfortunately, a DKIM signature can be replayed. This feature makes it difficult to attribute unsolicited messages to the domain applying the DKIM signature. Most likely, the guilty entity for sending unsolicited messages was a third-party service provider using harvested address lists acting on their behalf, but it could also have been from someone wanting to harm their reputation. Giving BofA a negative rating on the basis of a DKIM signature or an SPF authorization is unlikely to be effective at identifying the acting domain, and likely a reason for wanting to hint at the relative importance of the assumed source. White-listing domains is not effective at preventing undesired traffic when the domain does not identify the server originating the exchange. For reputation to be effective at blocking an entity causing problems, it must be based upon the administrative domain of the emitting server. Fairness requires that DKIM or SPF information be ignored when it does not identify the emitting server when establishing reputation ratings based on unsolicited traffic. Perhaps work being done on the keyassure reflector might result in a much needed EHLO authentication scheme. I would be interested in working on such an I-D. -Doug From vesely@tana.it Wed Aug 18 05:06:00 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 7F04D3A6870 for ; Wed, 18 Aug 2010 05:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.974 X-Spam-Level: X-Spam-Status: No, score=-3.974 tagged_above=-999 required=5 tests=[AWL=-0.745, 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 kB6mkKjq9qs9 for ; Wed, 18 Aug 2010 05:05:59 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 1BF553A68CF for ; Wed, 18 Aug 2010 05:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282133190; bh=GYamVL6PbZZM7pbjDix90lUkmZCzTg5jmFoydRw+5yw=; l=1870; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=frIvvqqGyStyodS/D9A+GPopOWGy7SX9GSvXQ5UdEcMpeJw/QCtQLViuGhPWx3Ph5 mHqAHC1Xa7SsT8OCdzUkOpOkMcqPFkzIz7rAoC1TZ97V3E5DAQ1nWAr9gbLt78YnT1 G7pyfs5VtCR3Gfb5U15od83t4O2F8GYzfoRRQYrc= Received: from [109.115.179.132] ([109.115.179.132]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 18 Aug 2010 14:06:29 +0200 id 00000000005DC035.000000004C6BCCC5.000006DD Message-ID: <4C6BCCB6.8090008@tana.it> Date: Wed, 18 Aug 2010 14:06:14 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> In-Reply-To: <4C6AE282.1070907@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 12:06:00 -0000 Douglas Otis wrote: > Unfortunately, most of the specifically relevant categories would relate > to undesired behaviors. > > - network scanning > - spamming > - malware distribution > - phishing > - denial of service attacks > - fast-flux domain activity > - compromised servers > - open proxies > - open relays > > With respect to email, some categories that would make sense is whether > they verify subscriptions, honor unsubscribe requests, or send > unsolicited messages. IMHO, reputation should stay one level higher than behavior. A classification, if any, must be such that domain owners will agree or propose the right class for their domains. > [...] > No single business category is immune from being compromised, or > prevents organized crime from acquiring all the related > infrastructure. In that regard, a category that indicates some entity > purports to be an acquiring bank means what exactly? IMHO, it means that any authenticated bad behavior was either the result of a compromised client or an employee acting incorrectly. Reputation should be related with how well they handle those incidents. In this respect, it is important that classifications reflect if/how responsibility for the domain behavior is distributed among registered users of the domain. I disagree that the IETF is unable to specify how reputation may be determined. How and where data is collected and collated may affect how it is queried and retrieved. That data does not exist already, AFAIK. The problem is to build the data, before we can query and retrieve it. Specifying a protocol that returns a quality triplet for each given token (URLs, IP addresses, restaurants, movies, or anything really) may be an interesting exercise in its own right. But it is not the central part of the problem. From dotis@mail-abuse.org Wed Aug 18 10:58:50 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 466C13A6844 for ; Wed, 18 Aug 2010 10:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.284 X-Spam-Level: X-Spam-Status: No, score=-106.284 tagged_above=-999 required=5 tests=[AWL=0.315, 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 J2uJarIcY0R2 for ; Wed, 18 Aug 2010 10:58:49 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 4FF783A6782 for ; Wed, 18 Aug 2010 10:58:49 -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 6E6DBA94615 for ; Wed, 18 Aug 2010 17:59:22 +0000 (UTC) Message-ID: <4C6C1F79.9000201@mail-abuse.org> Date: Wed, 18 Aug 2010 10:59:21 -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: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> In-Reply-To: <4C6BCCB6.8090008@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 17:58:50 -0000 On 8/18/10 5:06 AM, Alessandro Vesely wrote: > Douglas Otis wrote: >> Unfortunately, most of the specifically relevant categories would >> relate to undesired behaviors. >> >> - network scanning >> - spamming >> - malware distribution >> - phishing >> - denial of service attacks >> - fast-flux domain activity >> - compromised servers >> - open proxies >> - open relays >> >> With respect to email, some categories that would make sense is >> whether they verify subscriptions, honor unsubscribe requests, or >> send unsolicited messages. > IMHO, reputation should stay one level higher than behavior. A > classification, if any, must be such that domain owners will agree or > propose the right class for their domains. Class? As in first, second or third? What would class mean? If this relates to problematic protocols or how domains are authenticated, then I might agree. Reputation should _only_ reflect _verifiable_ and _authenticated_ online behavior. If you're not interested in online behavior, then use a D&B type of service unrelated to online behavior at your leisure. Unfortunately, many corporations become heavily compromised, which means ignoring their online behavior would not be beneficial. >> [...] >> No single business category is immune from being compromised, or >> prevents organized crime from acquiring all the related >> infrastructure. In that regard, a category that indicates some >> entity purports to be an acquiring bank means what exactly? > IMHO, it means that any authenticated bad behavior was either the > result of a compromised client or an employee acting incorrectly. > > Reputation should be related with how well they handle those > incidents. In this respect, it is important that classifications > reflect if/how responsibility for the domain behavior is distributed > among registered users of the domain. FWIW, reputation based upon online behavior should offer concise results that indicate whether a domain should be blocked. Such a service should also offer notifications to affected domains and allow a response before escalating to a recommendation of being blocked. > I disagree that the IETF is unable to specify how reputation may be > determined. How and where data is collected and collated may affect > how it is queried and retrieved. That data does not exist already, > AFAIK. The problem is to build the data, before we can query and > retrieve it. Agreed. Until email offers a method to authenticate issuing hosts, domain reputation is unable to offer much in the way of controlling abuse via domain names. Methods that assume a domain originated a message are destine to being gamed out of existence, and are wholly unsupportable. > Specifying a protocol that returns a quality triplet for each given > token (URLs, IP addresses, restaurants, movies, or anything really) > may be an interesting exercise in its own right. But it is not the > central part of the problem. Fully agree. -Doug From ajs@shinkuro.com Wed Aug 18 11:08:12 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 195433A69EF for ; Wed, 18 Aug 2010 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.686 X-Spam-Level: X-Spam-Status: No, score=-101.686 tagged_above=-999 required=5 tests=[AWL=0.913, 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 Z0PzYAcyUl4v for ; Wed, 18 Aug 2010 11:08:11 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 31D873A6984 for ; Wed, 18 Aug 2010 11:08:11 -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 3278D1ECB408 for ; Wed, 18 Aug 2010 18:08:46 +0000 (UTC) Date: Wed, 18 Aug 2010 14:08:44 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100818180844.GL92904@shinkuro.com> References: <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6C1F79.9000201@mail-abuse.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 18:08:12 -0000 On Wed, Aug 18, 2010 at 10:59:21AM -0700, Douglas Otis wrote: > Agreed. Until email offers a method to authenticate issuing hosts, > domain reputation is unable to offer much in the way of controlling > abuse via domain names. Again, I think I'm having a hard time understanding you. Are you suggesting that domain reputations are useless because they don't solve a particular email problem? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From dotis@mail-abuse.org Wed Aug 18 12:03: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 6FE673A6A8F for ; Wed, 18 Aug 2010 12:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.289 X-Spam-Level: X-Spam-Status: No, score=-106.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 aGNSfoaR8pYs for ; Wed, 18 Aug 2010 12:03:15 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id C07133A6A90 for ; Wed, 18 Aug 2010 12:03:03 -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 9917CA9471C for ; Wed, 18 Aug 2010 19:03:34 +0000 (UTC) Message-ID: <4C6C2E85.4020501@mail-abuse.org> Date: Wed, 18 Aug 2010 12:03:33 -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: <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <20100818180844.GL92904@shinkuro.com> In-Reply-To: <20100818180844.GL92904@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 19:03:16 -0000 On 8/18/10 11:08 AM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 10:59:21AM -0700, Douglas Otis wrote: > >> Agreed. Until email offers a method to authenticate issuing hosts, >> domain reputation is unable to offer much in the way of controlling >> abuse via domain names. > Again, I think I'm having a hard time understanding you. Are you > suggesting that domain reputations are useless because they don't > solve a particular email problem? The SMTP protocol, as specified, does not require any domain in a transaction to authenticate using some method. Reputation based upon the emitting host would not result in any source uncertainty, but there is no common practice for authenticating this with SMTP. I would be happy to write an I-D for SMTP Auth using a DKIM key that authenticates the host. SPF represents an authorization scheme referenced from some email element, where authorized servers often handle thousands of domains, and where these email elements are not normally nor necessarily bound to specific sources. Many suggest domains should be accountable for authorizations, however this would not allow domains a means to correct their reputation, nor be assured problems beyond their control do not reoccur. While some domains control the IP addresses and servers used, this is not the typical situation. Bad actors are expert at gaming uncertainties, which makes supporting an authorization scheme expensive, problematic and ultimately unfair. DKIM can be replayed by design. The replay feature makes it a poor identifier for controlling unsolicited email, because a valid signature does not indicate the intended recipient. -Doug From ajs@shinkuro.com Wed Aug 18 12:16: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 8EEAE3A6890 for ; Wed, 18 Aug 2010 12:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.712 X-Spam-Level: X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=0.887, 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 Yg+CPRIjtTxw for ; Wed, 18 Aug 2010 12:16:22 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9757F3A680D for ; Wed, 18 Aug 2010 12:16:22 -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 7821A1ECB408 for ; Wed, 18 Aug 2010 19:16:57 +0000 (UTC) Date: Wed, 18 Aug 2010 15:16:55 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20100818191655.GO92904@shinkuro.com> References: <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <20100818180844.GL92904@shinkuro.com> <4C6C2E85.4020501@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C6C2E85.4020501@mail-abuse.org> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 19:16:23 -0000 On Wed, Aug 18, 2010 at 12:03:33PM -0700, Douglas Otis wrote: > The SMTP protocol, as specified, does not require any domain in a > transaction to authenticate using some method. Reputation based upon the > emitting host would not result in any source uncertainty, but there is > no common practice for authenticating this with SMTP. I would be happy > to write an I-D for SMTP Auth using a DKIM key that authenticates the > host. So, then, if we _had_ a mechanism for people to, say, look up what you thought about a given domain, then it might be useful, no? > DKIM can be replayed by design. That's at least twice I've seen this assertion in this thread. What does it have to do with the rest of the topic? A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From msk@cloudmark.com Wed Aug 18 12:20:28 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 6B6F73A6A76 for ; Wed, 18 Aug 2010 12:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.341 X-Spam-Level: X-Spam-Status: No, score=-103.341 tagged_above=-999 required=5 tests=[AWL=-0.742, 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 0--Wvh2RM7tI for ; Wed, 18 Aug 2010 12:20:27 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 8E2773A6A59 for ; Wed, 18 Aug 2010 12:20:27 -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, 18 Aug 2010 12:21:02 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 18 Aug 2010 12:21:02 -0700 Thread-Topic: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) Thread-Index: Acs/Ce7ZcuNo6x3KTx6sf0DU4OfbvwAACB0g Message-ID: References: <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <20100818180844.GL92904@shinkuro.com> <4C6C2E85.4020501@mail-abuse.org> <20100818191655.GO92904@shinkuro.com> In-Reply-To: <20100818191655.GO92904@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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 19:20:28 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Andrew Sullivan > Sent: Wednesday, August 18, 2010 12:17 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A > sketch of a small query reputation system) >=20 > > DKIM can be replayed by design. >=20 > That's at least twice I've seen this assertion in this thread. What > does it have to do with the rest of the topic? I'm not sure why it's considered a serious threat in the first place. The = best you can do is replay an unmodified (subject to use of "l=3D") original= message. The worst this can be is annoying, not actually a security worry= (e.g. misrepresentation of content or of the originator). In any case, I don't see how one can include normative text about what doma= ins are valid for querying when we're talking about a protocol. That seems= to me to be as effective as RFC5322 saying the domain provided in the From= : header field has to be correct. We can provide all the informative text = about it we want, though. From dotis@mail-abuse.org Wed Aug 18 13:31:51 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 A8BD03A6859 for ; Wed, 18 Aug 2010 13:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.294 X-Spam-Level: X-Spam-Status: No, score=-106.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 bCEG2uuOK6o7 for ; Wed, 18 Aug 2010 13:31:49 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id AEDB23A67FB for ; Wed, 18 Aug 2010 13:31:49 -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 2C0A2A9478D for ; Wed, 18 Aug 2010 20:32:21 +0000 (UTC) Message-ID: <4C6C4355.9060007@mail-abuse.org> Date: Wed, 18 Aug 2010 13:32:21 -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: <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <20100818180844.GL92904@shinkuro.com> <4C6C2E85.4020501@mail-abuse.org> <20100818191655.GO92904@shinkuro.com> In-Reply-To: <20100818191655.GO92904@shinkuro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 18 Aug 2010 20:31:51 -0000 On 8/18/10 12:16 PM, Andrew Sullivan wrote: > On Wed, Aug 18, 2010 at 12:03:33PM -0700, Douglas Otis wrote: >> The SMTP protocol, as specified, does not require any domain in a >> transaction to authenticate using some method. Reputation based upon the >> emitting host would not result in any source uncertainty, but there is >> no common practice for authenticating this with SMTP. I would be happy >> to write an I-D for SMTP Auth using a DKIM key that authenticates the >> host. > So, then, if we _had_ a mechanism for people to, say, look up what you > thought about a given domain, then it might be useful, no? It would be useful to obtain information specific to how a domain is authenticated, and whether it currently is emitting undesired traffic not being mitigated. >> DKIM can be replayed by design. > That's at least twice I've seen this assertion in this thread. What > does it have to do with the rest of the topic? The majority of undesired traffic in email relates to "unsolicited" messages that are _not_ identified by their content. To be useful, email reputation deals with this significant aspect of undesired traffic, or it becomes difficult to justify the additional resources expended. These processes need to be automated, however a system based upon assumed sources allows bad actors an easy method to poison reputation information being collected, to the point where the system can not be used. -Doug From vesely@tana.it Thu Aug 19 02:32:43 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 728623A696B for ; Thu, 19 Aug 2010 02:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_40=-0.185, 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 K3MboUhC3D9M for ; Thu, 19 Aug 2010 02:32:41 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 940B03A6896 for ; Thu, 19 Aug 2010 02:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282210392; bh=kDut3wU0+aaDeHDq4HdaB1lavSZjuX3jEezUghdybaw=; l=2273; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Kp3E088bYOt996CmdVcxbfswq7P/z+2qcTnEkp1f8CeXSYuDxKQ+rAZeZ8HMxn4t7 2Jrn3sKoC/t4mslWOyY8LB+VDvTYDmKgXLGfp4OOzoQv3o3VChtmB424JKbC/1LfOM FheGyX0AQDbMj7kcex/AHKe/gu6rJhP/w2HpvDvw= Received: from [109.113.38.207] ([109.113.38.207]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Thu, 19 Aug 2010 11:33:11 +0200 id 00000000005DC035.000000004C6CFA57.00003771 Message-ID: <4C6CFA50.4050701@tana.it> Date: Thu, 19 Aug 2010 11:33:04 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> In-Reply-To: <4C6C1F79.9000201@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 19 Aug 2010 09:32:43 -0000 Douglas Otis wrote: > On 8/18/10 5:06 AM, Alessandro Vesely wrote: >> Douglas Otis wrote: >>> Unfortunately, most of the specifically relevant categories would >>> relate to undesired behaviors. >>> >>> - spamming >>> - [other behaviors elided] >>> >>> With respect to email, some categories that would make sense is >>> whether they verify subscriptions, honor unsubscribe requests, or >>> send unsolicited messages. >> IMHO, reputation should stay one level higher than behavior. A >> classification, if any, must be such that domain owners will agree or >> propose the right class for their domains. > Class? As in first, second or third? What would class mean? If this > relates to problematic protocols or how domains are authenticated, then > I might agree. Probably my English not supporting me. I just figured a hierarchy of classes (categories) and considered /classification/ as the process of assigning a class to each domain. Since the number of domains is huge, that is a daunting task. > Reputation should _only_ reflect _verifiable_ and _authenticated_ online > behavior. I don't fully agree, as I see no reason for the "only" requisite. The core of your statement hinges on /how/ reputation reflects online behavior. Indeed, working out this point is the central part of the problem that this WG-wannabe should elect to solve, IMHO. >>> [...] >> Reputation should be related with how well they handle those >> incidents. > FWIW, reputation based upon online behavior should offer concise results > that indicate whether a domain should be blocked. Nearly. IMHO, a receiver should handle with suspicion (or block), messages that are either unauthenticated or from domains with no reputation at all. If a reputation record can be found, the domain is a cooperative one and mail from it should be accepted. Abusive messages will then go through a reputation-driven process, and reputation itself will be adjusted according to its outcome. Abusive web content might be handled similarly. An additional advantage for web sites who register users, will be the ability to reckon the trustworthiness of newcomers based on their IDs' domain reputation --for "user@domain" IDs. From R.E.Sonneveld@sonnection.nl Thu Aug 19 08:45:56 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 25EBE3A696D for ; Thu, 19 Aug 2010 08:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.622 X-Spam-Level: X-Spam-Status: No, score=-3.622 tagged_above=-999 required=5 tests=[AWL=-2.118, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 dz3+5xsVoASZ for ; Thu, 19 Aug 2010 08:45:55 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id 0C2983A6912 for ; Thu, 19 Aug 2010 08:45:54 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed 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 <0L7E0000BP5EUE00@lion.sonnection.nl> for domainrep@ietf.org; Thu, 19 Aug 2010 17:46:27 +0200 (CEST) Message-id: <4C6D51D2.5000406@sonnection.nl> Date: Thu, 19 Aug 2010 17:46:26 +0200 From: "Rolf E. Sonneveld" User-Agent: Thunderbird 2.0.0.24 (X11/20100317) To: "Murray S. Kucherawy" References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> <4C6B05C0.7000405@sonnection.nl> In-reply-to: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1282232787; bh=HJghcdJKOqLhKY0vu0c//zye8o2fucrg7XhWKsdf94Q=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=bEAqQHD0pQODfzhS/iKjXJ5CEmgBsknNu1qlNkZuJrfPyllJq2hBGR6yR6TzNOu+s J35gKQu2OwwSgGkOAyuC8SNZkJtzJhyUWDqSf0ITzjv+J6gZA7fiI92/e/N07g+KCJ jks6kEv9LIe143/BgN4kCXsGrD7oZOd1DTW+QeuI= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7E0000BP5EUE00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 19 Aug 2010 15:45:56 -0000 Murray S. Kucherawy wrote: > > Well, DKIM for example defined a general “tag=value” syntax, then > declared set of tags it supports (some mandatory, some optional), and > then further specified that unknown tags must be ignored. Maybe a > protocol defined here specifies a general syntax and a minimum set of > known parameters (e.g. “r=” for the reputation and “c=” for the > confidence) and then the rest are either processed or ignored based on > what the client knows about the data the server will return. It’s nice > and extensible, provides a minimum implementation set, and is fairly > easy to parse. > I very much like this proposal as a starting point to design a model, which we can use to experiment with (I mean thought-experiments or experiments on paper) and which can lead to defining the real protocol. To use the 'characteristics' mentioned earlier on this list, the above two items: "r=" for reputation "c=" for confidence can be expanded to, for example: "i=" company or organization category (NAICS or other set) "t=" type or context, e.g. web, mail, sms, im etc. "h=" hash value, e.g. to contain the hash for a mail address, or for a URL (relative to domainname) etc. "f=" date/time of first abuse/malware/threat "l=" date/time of last abuse/malware/threat "n=" number of sources on which reputation decision is based "b=" type of information on which reputation is based (spf, dkim, spam report, virus report, or whatever) "e=" expires, maybe we want an expire date "?=" (I challenge all of us to come up with more characteristics which may be important in relation to reputation.) BTW: Maybe the hash value should not be part of these tags, but instead be part of the location in DNS (or whatever mechanism/storage is chosen) where the reputation data can be found. I suggest to start for each and every domain with a zero (0) value for reputation, which can grow to some positive value (e.g.) 9 or 99 or 255 and which can be decreased to some negative number (e.g.) -9, -99 or -255. A zero means: don't know, no information, or neutral. Another option would be here to use bit-encoded values. > Maybe an IANA registry of tags and their legal values and semantics? > Yes, IANA registry is important and should be described. Apart from the above, we need to define: a) the protocol to be used to retrieve this data: DNS, HTTP, LDAP, MySQL or whatever (being DNS the most likely candidate IMHO) b) the mechanism how c.q. the location where to find the reputation data in DNS (or other protocol) c) security considerations, especially things like risk of DDoS and how to defend against it d) etc. I'd be happy to make a start with a draft ID in which these things are addressed. The above does _only_ address the reputation protocol exchange, _not_ how reputation is determined, _nor_ how it's used by the reputation 'consumer', _nor_ whether the reputation data can be trusted etc., so it's entirely in scope of the discussion, I think. /rolf From johnl@iecc.com Thu Aug 19 09:56:03 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 6F85C3A697B for ; Thu, 19 Aug 2010 09:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.996 X-Spam-Level: X-Spam-Status: No, score=-109.996 tagged_above=-999 required=5 tests=[AWL=1.203, 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 c0rrp8V2FT5k for ; Thu, 19 Aug 2010 09:56:02 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id E52D03A696F for ; Thu, 19 Aug 2010 09:56:01 -0700 (PDT) Received: (qmail 49978 invoked from network); 19 Aug 2010 16:56:36 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 19 Aug 2010 16:56:36 -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=k1008; olt=johnl@user.iecc.com; bh=DOLpR697oowoLBZhp0dFUcUtQw6pfvLMe5iQrdEj/K0=; b=WPcqMFlXbN+1IQemfXzwbDf5LFt6bl5kB1Gq8EYBAegT8wBtFWjG2sfT4KfghOAm4Hd6hhdGWklEm+ysWRbzkdoVbmMC1W5G+RN6zb9BF5vS4e7oc+/+g3dllUUAC5Fc2WdB16DshniAJgN5+eWfFEc7nKUsphHbGYkvDEccvzA= Date: 19 Aug 2010 16:56:35 -0000 Message-ID: <20100819165635.29936.qmail@joyce.lan> From: John Levine To: domainrep@ietf.org In-Reply-To: <4C6D51D2.5000406@sonnection.nl> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Cc: R.E.Sonneveld@sonnection.nl Subject: Re: [domainrep] respponse bloat, was Industry taxonomies such as NAICS 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, 19 Aug 2010 16:56:03 -0000 >can be expanded to, for example: > >"i=" company or organization category (NAICS or other set) >"t=" type or context, e.g. web, mail, sms, im etc. [ and laundry list of other stuff ] This is the dossier model I mentioned. It seems unlikely to me that you could reasonably represent all the dossier info using short text strings (I want ma= for their full postal mailing address), and equally unlikely that it'll fit in a reasonably sized DNS response. That's why it's represented using an XML schema (to avoid inventing yet another complex ad-hoc syntax), and fetched using something like SOAP (to avoid inventing yet another heavyweight query scheme.) When I suggested that a short response should include a triple of score, confidence, and organization type, those weren't picked at random. They're the things that everyone (at the time) said they wanted. I'm not opposed to a dossier model, but I think it's important to distinguish between a fast lightweight model that's easy to use in realtime filtering because it has a small set of known fields, and a dossier that pretty much has to be stirred into an overall scoring system. R's, John From msk@cloudmark.com Thu Aug 19 10:00: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 7E67C3A6A58 for ; Thu, 19 Aug 2010 10:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.334 X-Spam-Level: X-Spam-Status: No, score=-103.334 tagged_above=-999 required=5 tests=[AWL=-0.735, 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 qb6aIOy-nuUR for ; Thu, 19 Aug 2010 10:00:31 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by core3.amsl.com (Postfix) with ESMTP id 8A6B33A6A55 for ; Thu, 19 Aug 2010 10:00:31 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Thu, 19 Aug 2010 10:01:06 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 19 Aug 2010 10:01:05 -0700 Thread-Topic: [domainrep] respponse bloat, was Industry taxonomies such as NAICS Thread-Index: Acs/v36HGgMob21rS9u8pf4fcvfbjAAADWHw Message-ID: References: <4C6D51D2.5000406@sonnection.nl> <20100819165635.29936.qmail@joyce.lan> In-Reply-To: <20100819165635.29936.qmail@joyce.lan> 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] respponse bloat, was Industry taxonomies such as NAICS 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, 19 Aug 2010 17:00:32 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of John Levine > Sent: Thursday, August 19, 2010 9:57 AM > To: domainrep@ietf.org > Cc: R.E.Sonneveld@sonnection.nl > Subject: Re: [domainrep] respponse bloat, was Industry taxonomies such > as NAICS >=20 > This is the dossier model I mentioned. It seems unlikely to me that > you could reasonably represent all the dossier info using short text > strings (I want ma=3D for their full postal mailing address), and > equally unlikely that it'll fit in a reasonably sized DNS response. > That's why it's represented using an XML schema (to avoid inventing > yet another complex ad-hoc syntax), and fetched using something like > SOAP (to avoid inventing yet another heavyweight query scheme.) > [...] > I'm not opposed to a dossier model, but I think it's important to > distinguish between a fast lightweight model that's easy to use in > realtime filtering because it has a small set of known fields, and a > dossier that pretty much has to be stirred into an overall scoring > system. There are also the obvious transport issues: The short model is fully resol= ved and easily parsed with a single UDP DNS query, while anything bigger th= an that will require either TCP DNS, or a full HTTP/XML/SOAP setup (or simi= lar) with somewhat more expensive parsing. One could certainly offer both, and we could specify the syntax of both as = well, to accommodate both worlds. From msk@cloudmark.com Thu Aug 19 10:05: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 88FAE3A69C5 for ; Thu, 19 Aug 2010 10:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.327 X-Spam-Level: X-Spam-Status: No, score=-103.327 tagged_above=-999 required=5 tests=[AWL=-0.728, 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 uh1OaOfas8EZ for ; Thu, 19 Aug 2010 10:05:30 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id AFFE83A6971 for ; Thu, 19 Aug 2010 10:05:30 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 19 Aug 2010 10:06:05 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 19 Aug 2010 10:06:04 -0700 Thread-Topic: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) Thread-Index: Acs/gZC/BTQwguG1T22jRsPvLjOpsAAPoz7g Message-ID: References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> In-Reply-To: <4C6CFA50.4050701@tana.it> 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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 19 Aug 2010 17:05:31 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Alessandro Vesely > Sent: Thursday, August 19, 2010 2:33 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A > sketch of a small query reputation system) >=20 > > Reputation should _only_ reflect _verifiable_ and _authenticated_ > online > > behavior. >=20 > I don't fully agree, as I see no reason for the "only" requisite. The > core > of your statement hinges on /how/ reputation reflects online behavior. > Indeed, working out this point is the central part of the problem that > this > WG-wannabe should elect to solve, IMHO. I still don't see how the IETF can specify how one goes about collecting an= d collating data to put into a reputation report of any kind. This makes a= bout as much sense to me as the IETF specifying how one filters spam; there= are countless algorithms, some effective and some not, some prone to false= positives and some not. There is no "right" mechanism; instead, people vo= te with their proverbial feet as particular algorithms prove (or fail to pr= ove) their efficacy. The mechanism by which one presents an object for evaluation and gets a rep= ort about it is a matter of protocol, and we can specify that. The rest is= what I've been calling "secret sauce" and we have no business meddling in = that area, nor can we possibly think stipulating how one picks what objects= to present for evaluation, in a normative sense, is even worth trying to d= o. I do, however, think providing as part of the report some hints about how t= he results were determined might be useful. From jdfalk-lists@cybernothing.org Thu Aug 19 10:10: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 64B283A6987 for ; Thu, 19 Aug 2010 10:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1rHfGE5Ueem for ; Thu, 19 Aug 2010 10:10:15 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id ADAB33A693D for ; Thu, 19 Aug 2010 10:10: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 o7JHAkCx030698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 19 Aug 2010 10:10:49 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7JHAkCx030698 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282237849; bh=AS2EeuiZnqS5Cz/OetsspG6xPpJzOeYR6yXTRdiNH gg=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=f1iIkCeDK7GQBRT3 Hle5baEdQqkAieGHIiIWAaqybElWH1PwDRusPYTBvHsB/rawg/AXFVB2Sk8xmEVyvM3 pUIQ2/1OV1uJHV14MxEQvv/+bXS8TCrfmv15Udu3j3E/ZNg2SQZWoRJjk81y9qS6JUZ gn9LSDJt28bclr6T6Wjk4= References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> <4C6B05C0.7000405@sonnection.nl> <4C6D51D2.5000406@sonnection.nl> In-Reply-To: <4C6D51D2.5000406@sonnection.nl> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 Message-Id: <42883F84-A0B5-4494-864B-C816F539DE46@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 19 Aug 2010 10:10:46 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: [domainrep] towards a first draft (was Re: Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system)) 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, 19 Aug 2010 17:10:18 -0000 On Aug 19, 2010, at 8:46 AM, Rolf E. Sonneveld wrote: > I'd be happy to make a start with a draft ID in which these things are = addressed. The above does _only_ address the reputation protocol = exchange, _not_ how reputation is determined, _nor_ how it's used by the = reputation 'consumer', _nor_ whether the reputation data can be trusted = etc., so it's entirely in scope of the discussion, I think. [as co-chair] I agree -- and many thanks for the offer. I think it'd = help everyone immensely to see this part of the discussion codified into = a draft, so we can look at it as a whole. [replying as a participant for the remainder] > Murray S. Kucherawy wrote: >>=20 >> Well, DKIM for example defined a general =93tag=3Dvalue=94 syntax, = then declared set of tags it supports (some mandatory, some optional), = and then further specified that unknown tags must be ignored. Maybe a = protocol defined here specifies a general syntax and a minimum set of = known parameters (e.g. =93r=3D=94 for the reputation and =93c=3D=94 for = the confidence) and then the rest are either processed or ignored based = on what the client knows about the data the server will return. It=92s = nice and extensible, provides a minimum implementation set, and is = fairly easy to parse. >=20 > I very much like this proposal as a starting point to design a model, = which we can use to experiment with (I mean thought-experiments or = experiments on paper) and which can lead to defining the real protocol. = To use the 'characteristics' mentioned earlier on this list, the above = two items: >=20 > "r=3D" for reputation > "c=3D" for confidence >=20 > can be expanded to, for example: >=20 > "i=3D" company or organization category (NAICS or other set) Probably also need a tag (and an IANA registry) to identify which = categorization authority is being used. > "t=3D" type or context, e.g. web, mail, sms, im etc. Would it be sufficient to use URI scheme names here? > "h=3D" hash value, e.g. to contain the hash for a mail address, or for = a URL (relative to domainname) etc. Does it have to be hashed? I can imagine valid arguments either way.... > "f=3D" date/time of first abuse/malware/threat > "l=3D" date/time of last abuse/malware/threat > "n=3D" number of sources on which reputation decision is based > "b=3D" type of information on which reputation is based (spf, dkim, = spam report, virus report, or whatever) > "e=3D" expires, maybe we want an expire date > "?=3D" (I challenge all of us to come up with more characteristics = which may be important in relation to reputation.) I challenge all of us to keep the number of default characteristics to a = minimum. *grin* Also, I imagine most of these are optional? I wouldn't want to create a = protocol that can't be used to convey exactly the same data as all the = existing systems. From jdfalk-lists@cybernothing.org Thu Aug 19 10:16:17 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 5DFF83A67F1 for ; Thu, 19 Aug 2010 10:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 GrVEvFEOuhww for ; Thu, 19 Aug 2010 10:16:15 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id E61133A697F for ; Thu, 19 Aug 2010 10:16: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 o7JHGlLO030767 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 19 Aug 2010 10:16:49 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7JHGlLO030767 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282238209; bh=rorTdf96o+RUiZToxblfsALCLi20Hul826ss5x5i4 c8=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=CALYxPG3WHLAJ+5w CXjXfJzvrgXZhXml+PZtwT6so6p8DotgubLvgBuVKDosqNly5xIszILKgRLi+bw8d7G ycEM4Gcd/3dCm65LpctqVshlGu9YBOrKgyPwkiNYx/PR4aGLJMB9G0nQlMJB6vutsdc +8wQVmELJTZGTeyYH7tiI= References: <20100819165635.29936.qmail@joyce.lan> In-Reply-To: <20100819165635.29936.qmail@joyce.lan> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <733950DF-E035-48EA-9A78-E280553A0377@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Thu, 19 Aug 2010 10:16:47 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] response bloat, was Industry taxonomies such as NAICS 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, 19 Aug 2010 17:16:17 -0000 On Aug 19, 2010, at 9:56 AM, John Levine wrote: > This is the dossier model I mentioned. It seems unlikely to me that > you could reasonably represent all the dossier info using short text > strings (I want ma=3D for their full postal mailing address), and > equally unlikely that it'll fit in a reasonably sized DNS response. > That's why it's represented using an XML schema (to avoid inventing > yet another complex ad-hoc syntax), and fetched using something like > SOAP (to avoid inventing yet another heavyweight query scheme.) >=20 > When I suggested that a short response should include a triple of > score, confidence, and organization type, those weren't picked at > random. They're the things that everyone (at the time) said they > wanted. I'd expect once we've got the initial list of fields -- in any form -- = it'll be easier to see what works as tag=3Dvalue and what needs XML. I could easily imagine one of the tags containing an HTTP URL to a SOAP = service which contains more detailed info, for use when those details = are desired...but I'm not so certain that those details will actually be = used for anything except manual debugging processes. From msk@cloudmark.com Thu Aug 19 10:27:35 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 8A8D43A69A2 for ; Thu, 19 Aug 2010 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.32 X-Spam-Level: X-Spam-Status: No, score=-103.32 tagged_above=-999 required=5 tests=[AWL=-0.721, 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 qv5Fczr86u3g for ; Thu, 19 Aug 2010 10:27:34 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id B160A3A6980 for ; Thu, 19 Aug 2010 10:27:34 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 19 Aug 2010 10:28:09 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 19 Aug 2010 10:28:08 -0700 Thread-Topic: [domainrep] towards a first draft (was Re: Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system)) Thread-Index: Acs/wXwHlcDSuOcySA63GbG1Xy2FzAAAjXzA Message-ID: References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> <4C6B05C0.7000405@sonnection.nl> <4C6D51D2.5000406@sonnection.nl> <42883F84-A0B5-4494-864B-C816F539DE46@cybernothing.org> In-Reply-To: <42883F84-A0B5-4494-864B-C816F539DE46@cybernothing.org> 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] towards a first draft (was Re: Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system)) 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, 19 Aug 2010 17:27:35 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of J.D. Falk > Sent: Thursday, August 19, 2010 10:11 AM > To: domainrep@ietf.org > Subject: [domainrep] towards a first draft (was Re: Industry taxonomies > such as NAICS (was Re: A sketch of a small query reputation system)) >=20 > > "t=3D" type or context, e.g. web, mail, sms, im etc. >=20 > Would it be sufficient to use URI scheme names here? Is there a registered URI prefix for SMS or IM? > > "h=3D" hash value, e.g. to contain the hash for a mail address, or for > a URL (relative to domainname) etc. >=20 > Does it have to be hashed? I can imagine valid arguments either > way.... I'm not sure I understand the need for this one at all. Doesn't this mean = the server is replying to the client with a hash of the question it was ask= ed? What would that be for? From R.E.Sonneveld@sonnection.nl Thu Aug 19 10:48:57 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 31D1D3A6847 for ; Thu, 19 Aug 2010 10:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=-1.986, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 JavRRTosIgJv for ; Thu, 19 Aug 2010 10:48:56 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id 9B23A3A67FE for ; Thu, 19 Aug 2010 10:48:55 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed 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 <0L7E0000QUUHUE00@lion.sonnection.nl> for domainrep@ietf.org; Thu, 19 Aug 2010 19:49:30 +0200 (CEST) Message-id: <4C6D6EA9.4020908@sonnection.nl> Date: Thu, 19 Aug 2010 19:49:29 +0200 From: "Rolf E. Sonneveld" User-Agent: Thunderbird 2.0.0.24 (X11/20100317) To: "J.D. Falk" References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <20100817195552.GB89703@shinkuro.com> <4C6B05C0.7000405@sonnection.nl> <4C6D51D2.5000406@sonnection.nl> <42883F84-A0B5-4494-864B-C816F539DE46@cybernothing.org> In-reply-to: <42883F84-A0B5-4494-864B-C816F539DE46@cybernothing.org> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1282240170; bh=0uKIzIvu1x/n/W6b1Or1XrTJ1OnXe4dn/3Q1Ydi0Ya0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=A8N82bR77VRdlcEW+INl1ZjMCXNiF0emTRumI8bCDLzAGOP435juk/7dg/ThlWugk gxOBdjaehg3ocygljAJbtlQEFaVbcXz5Zjj9zjucZCnPMHZIrH9teGBDdpcQAet+1P 2Ue96GtCnTp6CXx2JEMF0V2UgQ44z+7laTjdJZUQ= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7E0000QUUHUE00 Cc: domainrep@ietf.org Subject: Re: [domainrep] towards a first draft (was Re: Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system)) 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, 19 Aug 2010 17:48:57 -0000 J.D. Falk wrote: > On Aug 19, 2010, at 8:46 AM, Rolf E. Sonneveld wrote: > > >> I'd be happy to make a start with a draft ID in which these things are addressed. The above does _only_ address the reputation protocol exchange, _not_ how reputation is determined, _nor_ how it's used by the reputation 'consumer', _nor_ whether the reputation data can be trusted etc., so it's entirely in scope of the discussion, I think. >> > > [as co-chair] I agree -- and many thanks for the offer. I think it'd help everyone immensely to see this part of the discussion codified into a draft, so we can look at it as a whole. > > > [replying as a participant for the remainder] > > >> Murray S. Kucherawy wrote: >> >>> Well, DKIM for example defined a general “tag=value” syntax, then declared set of tags it supports (some mandatory, some optional), and then further specified that unknown tags must be ignored. Maybe a protocol defined here specifies a general syntax and a minimum set of known parameters (e.g. “r=” for the reputation and “c=” for the confidence) and then the rest are either processed or ignored based on what the client knows about the data the server will return. It’s nice and extensible, provides a minimum implementation set, and is fairly easy to parse. >>> >> I very much like this proposal as a starting point to design a model, which we can use to experiment with (I mean thought-experiments or experiments on paper) and which can lead to defining the real protocol. To use the 'characteristics' mentioned earlier on this list, the above two items: >> >> "r=" for reputation >> "c=" for confidence >> >> can be expanded to, for example: >> >> "i=" company or organization category (NAICS or other set) >> > > Probably also need a tag (and an IANA registry) to identify which categorization authority is being used. > > >> "t=" type or context, e.g. web, mail, sms, im etc. >> > > Would it be sufficient to use URI scheme names here? > The idea is attractive, but I don't think it will cover all possible contexts. >> "h=" hash value, e.g. to contain the hash for a mail address, or for a URL (relative to domainname) etc. >> > > Does it have to be hashed? Not necessarily. > I can imagine valid arguments either way.... > Agreed. Let's sideline it for a moment, to discuss this later. >> "f=" date/time of first abuse/malware/threat >> "l=" date/time of last abuse/malware/threat >> "n=" number of sources on which reputation decision is based >> "b=" type of information on which reputation is based (spf, dkim, spam report, virus report, or whatever) >> "e=" expires, maybe we want an expire date >> "?=" (I challenge all of us to come up with more characteristics which may be important in relation to reputation.) >> > > I challenge all of us to keep the number of default characteristics to a minimum. *grin* > +1. It was not my intention to make the list as long as possible, I only wanted to appeal on the creativity of all of us, as we were running more or less in circles, without exploring any other possibly important aspects of reputation. So I fully agree: the list should be as short as possible - but not shorter. > Also, I imagine most of these are optional? I wouldn't want to create a protocol that can't be used to convey exactly the same data as all the existing systems. > I'm pretty sure that we will see that most of them are optional, having the two or three mentioned by John as the mandatory tags/fields (I'm not sure the industry/taxonomy tag needs to be defined as mandatory). /rolf From dotis@mail-abuse.org Thu Aug 19 11:06:13 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 36F233A69E1 for ; Thu, 19 Aug 2010 11:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.298 X-Spam-Level: X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 GHANKQzPeObp for ; Thu, 19 Aug 2010 11:06:11 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 3842C3A6844 for ; Thu, 19 Aug 2010 11:06:11 -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 988CBA94475 for ; Thu, 19 Aug 2010 18:06:41 +0000 (UTC) Message-ID: <4C6D729F.1080504@mail-abuse.org> Date: Thu, 19 Aug 2010 11:06:23 -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: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 19 Aug 2010 18:06:13 -0000 On 8/19/10 10:06 AM, Murray S. Kucherawy wrote: > On 8/18/10 1:32 PM, Douglas Otis > > On Thursday, August 19, 2010 2:33 AM Alessandro Vesely wrote: > >> Reputation should _only_ reflect _verifiable_ and > >> _authenticated_ online behavior. > > > > I don't fully agree, as I see no reason for the "only" requisite. > > The core of your statement hinges on /how/ reputation reflects > > online behavior. Indeed, working out this point is the central part > > of the problem that this WG-wannabe should elect to solve, IMHO. > > I still don't see how the IETF can specify how one goes about > collecting and collating data to put into a reputation report of any > kind. The draft should require data collected that negatively affects a domain's reputation be authenticated. > This makes about as much sense to me as the IETF specifying how one > filters spam; there are countless algorithms, some effective and some > not, some prone to false positives and some not. There is no "right" > mechanism; instead, people vote with their proverbial feet as > particular algorithms prove (or fail to prove) their efficacy. Not being able to provide evidence justifying a domain's reputation represents a likely disruptive and unfair service. In principle, the basis for negative reputation MUST be authenticated. For IP addresses, this might include a TCP exchange of several packets. For Domains this should be specified for each type of protocol assessed for specific behaviors. > The mechanism by which one presents an object for evaluation and gets > a report about it is a matter of protocol, and we can specify that. Agreed. > The rest is what I've been calling "secret sauce" and we have no > business meddling in that area, nor can we possibly think stipulating > how one picks what objects to present for evaluation, in a normative > sense, is even worth trying to do. Would you be happy having your DOMAIN blocked by a service that is not obligated to offer any authenticated evidence justifying the negative ratings given for your DOMAIN? The magnitude of a rating is not important. However, the range of values representing negative reputations, and values that represents an "unknown" reputation MUST be specified. > I do, however, think providing as part of the report some hints about > how the results were determined might be useful. Hints? -Doug From msk@cloudmark.com Thu Aug 19 11:16:26 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 0FEC33A6801 for ; Thu, 19 Aug 2010 11:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=-0.726, 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 MJ9zSOXQxRX4 for ; Thu, 19 Aug 2010 11:16:25 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by core3.amsl.com (Postfix) with ESMTP id 268B23A6844 for ; Thu, 19 Aug 2010 11:16:25 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Thu, 19 Aug 2010 11:17:00 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Thu, 19 Aug 2010 11:16:58 -0700 Thread-Topic: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) Thread-Index: Acs/yU1BgZTiJ23fSwyQL1KIuqEuvwAAHymQ Message-ID: References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> <4C6D729F.1080504@mail-abuse.org> In-Reply-To: <4C6D729F.1080504@mail-abuse.org> 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] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 19 Aug 2010 18:16:26 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Douglas Otis > Sent: Thursday, August 19, 2010 11:06 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A > sketch of a small query reputation system) >=20 > > I still don't see how the IETF can specify how one goes about > > collecting and collating data to put into a reputation report of any > > kind. >=20 > The draft should require data collected that negatively affects a > domain's reputation be authenticated. How is that part of a protocol design and not an implementation decision? > > This makes about as much sense to me as the IETF specifying how one > > filters spam; there are countless algorithms, some effective and > some > > not, some prone to false positives and some not. There is no > "right" > > mechanism; instead, people vote with their proverbial feet as > > particular algorithms prove (or fail to prove) their efficacy. >=20 > Not being able to provide evidence justifying a domain's reputation > represents a likely disruptive and unfair service. ...which people would avoid by seeking that service from some other provide= r. This doesn't belong in a protocol specification. > Would you be happy having your DOMAIN blocked by a service that is not > obligated to offer any authenticated evidence justifying the negative > ratings given for your DOMAIN? Yes. If people want mail from my domain and they find some reputation prov= ider is giving my domain a negative rating with no basis, they will either = whitelist me or find a more accurate provider. This is not a new concept; = think RBLs. Justifying it in the answer is fine. Regulating how a provider comes up wi= th the answer does not belong in a protocol specification. > The magnitude of a rating is not > important. However, the range of values representing negative > reputations, and values that represents an "unknown" reputation MUST be > specified. Sure, THAT is a valid part of a protocol specification. From johnl@iecc.com Thu Aug 19 11:55: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 577553A6982 for ; Thu, 19 Aug 2010 11:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.012 X-Spam-Level: X-Spam-Status: No, score=-110.012 tagged_above=-999 required=5 tests=[AWL=1.187, 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 0ExlvYG3AAvh for ; Thu, 19 Aug 2010 11:55:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 0092A3A6862 for ; Thu, 19 Aug 2010 11:55:39 -0700 (PDT) Received: (qmail 9940 invoked from network); 19 Aug 2010 18:56:14 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 19 Aug 2010 18:56:14 -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=k1008; olt=johnl@user.iecc.com; bh=HC2Iqa2p9K0iyEVc66XCGzmPpzYfX1m6Xf/KkTyD99Y=; b=Ran0KZc0OSCZaE1w0JYJdHy6y3Zp6W3nBLsVPuJ9y85z0TZGWxc+OExGdJRLn7A0UPbQIgG0YL1f1lKVK62gE83XkvVC6hF3fHTlaw1ro5dzmAK5PXGSDAHN9DJehrGrSQ+6HgfVXOhWUV+puEOX5hvqdFa2O0CcdpAVU0JLVyo= Date: 19 Aug 2010 18:56:14 -0000 Message-ID: <20100819185614.59015.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] towards a first draft (was Re: Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system)) 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, 19 Aug 2010 18:55:41 -0000 >> Would it be sufficient to use URI scheme names here? > >Is there a registered URI prefix for SMS or IM? For SMS, RFC 5724 defines the sms: URI. For IM, RFC 3860 defines the im: URI. I have my doubts as to how useful this would be in a reputation lookup, but there's no need to reinvent them if so. R's, John From vesely@tana.it Fri Aug 20 02:48:19 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 449BF3A696B for ; Fri, 20 Aug 2010 02:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.347 X-Spam-Level: X-Spam-Status: No, score=-4.347 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, 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 GeWHvHxl30jQ for ; Fri, 20 Aug 2010 02:48:18 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id AE79C3A69EA for ; Fri, 20 Aug 2010 02:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282297727; bh=Pv3BmHULYsLlUC4bJ5a59QzXh3lCUvoddIg4aVX30Q8=; l=2657; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=GlH7J3CF84Sen3iitJPfMWLuNg1qJr15z34jv/sCR/d3NaXc+/FmoAn2W/wfUVWJX 5REIF5CUyUAQotfWuyZ0vdqzMWvl0kXkbY+0CLLKQ28nou4gMdYxKO9roVljvSh9qV DQm8hUBhwuAtiAkHyPqoZd6QppnMZpN6jnmCYu+g= Received: from [109.115.161.58] ([109.115.161.58]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Fri, 20 Aug 2010 11:48:46 +0200 id 00000000005DC03B.000000004C6E4F7F.0000096B Message-ID: <4C6E4F79.9090900@tana.it> Date: Fri, 20 Aug 2010 11:48:41 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "domainrep@ietf.org" References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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: Fri, 20 Aug 2010 09:48:19 -0000 Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Alessandro Vesely >> >>> Reputation should _only_ reflect _verifiable_ and _authenticated_ >>> online behavior. >> I don't fully agree, as I see no reason for the "only" requisite. The core >> of your statement hinges on /how/ reputation reflects online behavior. >> Indeed, working out this point is the central part of the problem that this >> WG-wannabe should elect to solve, IMHO. > > I still don't see how the IETF can specify how one goes about collecting > and collating data to put into a reputation report of any kind. Nor I. But that's because we haven't worked out that point, yet. However, there is a decent understanding of how generalized FBLs can be standardized, and that part may somehow include details about how to select a reputation tracker. > This makes about as much sense to me as the IETF specifying how one > filters spam; there are countless algorithms, some effective and some not, > some prone to false positives and some not. There is no "right" > mechanism; instead, people vote with their proverbial feet as particular > algorithms prove (or fail to prove) their efficacy. Yes, the IETF might standardize Bayesian filters, since they are already specified. And that is not a cooperative process. OTOH, MARID has proved that a specifications not invented within the IETF have fewer possibilities of being standardized either. A possible solution is that this group agrees on a cooperation model. What will be standardized are the interfaces whereby cooperation may be achieved. > The mechanism by which one presents an object for evaluation and gets a > report about it is a matter of protocol, and we can specify that. Yes, querying is one of those interfaces. > The rest is what I've been calling "secret sauce" and we have no business > meddling in that area, How much will it cost to discover all domains and subdomains and classify them according to NAICS? How much will they have to charge in order to reach a break even after N years? It is not realistic _not_ to ask these questions. > nor can we possibly think stipulating how one picks what objects to > present for evaluation, in a normative sense, is even worth trying to do. > I do, however, think providing as part of the report some hints about how > the results were determined might be useful. Yes, we agreed something similar about suggesting how to determine whether it is safe to forward an abuse report to some site. Hopefully, the two sets of suggestions will match with one another :-) From dotis@mail-abuse.org Fri Aug 20 11:16:57 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 DC1243A6B2A for ; Fri, 20 Aug 2010 11:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.307 X-Spam-Level: X-Spam-Status: No, score=-106.307 tagged_above=-999 required=5 tests=[AWL=0.292, 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 A2ZkUoBDmSV1 for ; Fri, 20 Aug 2010 11:16:56 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 96E6F3A6B32 for ; Fri, 20 Aug 2010 11:16:53 -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 9A548A9467E for ; Fri, 20 Aug 2010 18:17:22 +0000 (UTC) Message-ID: <4C6EC6B1.2010303@mail-abuse.org> Date: Fri, 20 Aug 2010 11:17:21 -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: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> <4C6D729F.1080504@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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: Fri, 20 Aug 2010 18:16:57 -0000 On 8/19/10 11:16 AM, Murray S. Kucherawy wrote: > > On Thursday, August 19, 2010 11:06 AM Douglas Otis wrote: > > > > The draft should require data collected that negatively affects a > > domain's reputation be authenticated. > > How is that part of a protocol design and not an implementation > decision? This type of statement should be within the Security Consideration section. George Fuechsel's expression Garbage In, Garbage Out applies in this case. Allowing garbage in (assumed sources) will result in denial of service issues. While no RFC really prevents ill advised practices, at least it should include guiding principles such as "data used to assign negative reputations MUST be authenticated". Bad actors do and will attempt to poison a system that interferes with their activities. > > Not being able to provide evidence justifying a domain's > > reputation represents a likely disruptive and unfair service. > > ...which people would avoid by seeking that service from some other > provider. > > This doesn't belong in a protocol specification. Strongly disagree. Not authenticating data used to establish negative reputations represents a security issue when this potentially disrupts an ENTIRE DOMAIN without them having any effective recourse! > > Would you be happy having your DOMAIN blocked by a service that is > > not obligated to offer any authenticated evidence justifying the > > negative ratings given for your DOMAIN? > > Yes. If people want mail from my domain and they find some > reputation provider is giving my domain a negative rating with no > basis, they will either whitelist me or find a more accurate > provider. This is not a new concept; think RBLs. RBLs typically involved reputations based upon the end point of TCP traffic from a particular IP address, where in our case, this also involved monitoring BGP and retaining evidence supporting our assertions. Domains however deserve even greater care. The draft should clearly make this point. > Justifying it in the answer is fine. Regulating how a provider comes > up with the answer does not belong in a protocol specification. Saying that the data should be authenticated does not necessarily indicate how. > > The magnitude of a rating is not important. However, the range of > > values representing negative reputations, and values that > > represents an "unknown" reputation MUST be specified. > > Sure, THAT is a valid part of a protocol specification. Great. -Doug From vesely@tana.it Sat Aug 21 03:03: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 89BA33A682F for ; Sat, 21 Aug 2010 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_27=0.6, 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 xsr1LcJtCYNk for ; Sat, 21 Aug 2010 03:03:01 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id E3BFD3A67E1 for ; Sat, 21 Aug 2010 03:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282385011; bh=VhFK2hKja20g3nNijCWQPY3/0e46Noe6jtl9JGAv2NI=; l=2316; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=NrK2uOGkGdkibv57ub78eIjItFDrspWo0t68+JW84Rb78iktcDxVJFR9vBqy21K4m rDtyK4YnqrPwVxmWNA1xctT070v8dbSQ/Ni5J/5Nmrc8iJaE6d2/jaTVtyoLiJxT4H qN5A4LJt93Y/T4mflbanOwHKGPl1uYIX2uvE8aI8= Received: from [109.115.165.112] (softdnserr [109.115.165.112]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Sat, 21 Aug 2010 12:03:30 +0200 id 00000000005DC031.000000004C6FA472.000049EB Message-ID: <4C6FA44C.6010100@tana.it> Date: Sat, 21 Aug 2010 12:02:52 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> <4C6D729F.1080504@mail-abuse.org> In-Reply-To: <4C6D729F.1080504@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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: Sat, 21 Aug 2010 10:03:03 -0000 Douglas Otis wrote: > On 8/19/10 10:06 AM, Murray S. Kucherawy wrote: >> This makes about as much sense to me as the IETF specifying how one >> filters spam; there are countless algorithms, some effective and some >> not, some prone to false positives and some not. There is no "right" >> mechanism; instead, people vote with their proverbial feet as >> particular algorithms prove (or fail to prove) their efficacy. > > Not being able to provide evidence justifying a domain's reputation > represents a likely disruptive and unfair service. In principle, the > basis for negative reputation MUST be authenticated. For IP addresses, > this might include a TCP exchange of several packets. For Domains this > should be specified for each type of protocol assessed for specific > behaviors. Correct. However, negative contributions to a domain's reputation should be exceptional means to reproach that domain's admins, e.g. in case they fail to properly handle an incident. > Would you be happy having your DOMAIN blocked by a service that is not > obligated to offer any authenticated evidence justifying the negative > ratings given for your DOMAIN? The magnitude of a rating is not > important. However, the range of values representing negative > reputations, and values that represents an "unknown" reputation MUST be > specified. There is no point in setting global negative values for a domain's reputation. Persistent abusers will just change to new domain names. Reputation must reflect good behavior. How do we establish a new domain's positive reputation? Let me draw a tentative sketch: The admins of ND.example fill out a simple module aimed at determining ND's position in our taxonomy. Some other domains, which we may call ND's "friends", check the answers given, and reward their correctness with a score. These scores contribute to the ND's reputation. In order to avoid gaming, ND's reputation will have different values according to the /web of trust/ of the enquirer: when one of the friend domains queries ND's reputation, the score they gave to it is preponderant; However, if there is no trust-path from an enquirer to the ND's friends, the enquirer sees no reputation at all. -- From nsb@guppylake.com Sun Aug 22 10:56:01 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 E82633A68BB for ; Sun, 22 Aug 2010 10:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 TJDNK+Xxlhyj for ; Sun, 22 Aug 2010 10:56:00 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 9BF0A3A677C for ; Sun, 22 Aug 2010 10:56:00 -0700 (PDT) Received: from [108.120.7.60] (helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OnEzI-0004CR-5O for domainrep@ietf.org; Sun, 22 Aug 2010 14:09:44 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1081) From: Nathaniel Borenstein In-Reply-To: <20100816231607.29638.qmail@joyce.lan> Date: Sun, 22 Aug 2010 13:56:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100816231607.29638.qmail@joyce.lan> 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] Why Industry codes? Why not reputation-aspect codes? 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: Sun, 22 Aug 2010 17:56:02 -0000 The more I read about NAICS and its ilk, the more I feel like going back = to first principles. Why do we need an industry code, and what does it = mean? Is there a meaningful industry code for a company like IBM, that = plays in nearly every part of the computer industry, or GE, which plays = a huge variety of roles in many industries? Do we really want or need = to base reputations (and ensuing actions) on the best-fit industry role = that someone -- we still don't know who or how or when -- has selected = for a company? And can we really justify the cost of everyone taking = the time to decide on these industry codes? This all feels like a = rathole to me. Perhaps we should instead work towards a taxonomy of the particular = (behavioral) attributes about which we're reporting reputation = information. In the real world, if I had to choose between two people, = one of whom was a known financial criminal and one of whom was a known = child molester, I would choose the former in a heartbeat if I was = looking a babysitter for my children. But if I was looking for someone = to mind my lemonade stand while I took a break, I might well go with the = pervert. And none of this criminal information would be helpful in = trying to decide whether or not to accept email from one of their = private domains. (A kiddie porn website that behaves well in terms of = malware probably deserves a very limited kind of good reputation.) So I find myself wondering: Perhaps we should be worrying about = taxonomizing threat types rather than industry codes? Then we might say = that ge.com has a good reputation for not sending spam, but (in a = whimsical future extension) a bad reputation for overcharging consumers = on credit card fees. A particular ISP might have a good reputation for = responding quickly to incident reports, but a bad reputation for keeping = spam out of its outgoing mail. And so on. I'm guessing that the desire for industry codes is really motivated by a = few specific use cases that might just as well be handled by a threat = taxonomy. Instead of identifying citibank.com as some kind of bank, we = could just make it possible to say that it has an extremely low score on = pretending falsely to be a bank, which is one of the (relatively few, = compared with NAICS categories) specific threats we're worried about. = -- Nathaniel From johnl@iecc.com Sun Aug 22 19:36:45 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 3B0063A6993 for ; Sun, 22 Aug 2010 19:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.972 X-Spam-Level: X-Spam-Status: No, score=-108.972 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_20=-0.74, 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 hR3nFp5s1JKI for ; Sun, 22 Aug 2010 19:36:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id A4BF53A6987 for ; Sun, 22 Aug 2010 19:36:27 -0700 (PDT) Received: (qmail 45459 invoked from network); 23 Aug 2010 02:35:41 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 23 Aug 2010 02:35:41 -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=k1008; olt=johnl@user.iecc.com; bh=f/S55UQYFMF1Z1jZjgDlybge+qKaKy0VRoA4LXD1sbA=; b=yziuqaEmNH5RwyRlp6PP5amm6KbpBAtj793g4x7imFu0R+eh4ofUc7mkGYxtGk68s+YaT4B6J9oxlS4ZMwOQhAQU4LcL/wCgEPb9102EbBlZDR+u4uoDGwVRN/vbqzSn0XIZhhl9C1JnuTr9shIO6aBJfGdCl4VLQIXrY3jjbgQ= Date: 23 Aug 2010 02:35:36 -0000 Message-ID: <20100823023536.30581.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] Why Industry codes? Why not reputation-aspect codes? 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, 23 Aug 2010 02:36:45 -0000 >I'm guessing that the desire for industry codes is really motivated by a >few specific use cases that might just as well be handled by a threat >taxonomy. I don't think so. Banks are a somewhat unusual case in that they tend to be phish targets, and that in most countries they are regulated by the government so it is possible to get a definitive list of the genuine banks. (Yes, there are arcane corner cases. A reputation system does not have to cover the entire universe, so it doesn't matter.) I want to know is "this is a bank", not "this is an entity that has not been observed to send bank phishes." If I know mail is really from a bank, I might want to deliver it even if it smells spammy since the potential damage of doing so is low. Note that a rather coarse taxonomy is fine here, it's unlikely to be useful to know the difference among the zillion types of central European banks that Stephen mentioned. I'm not sure what other categories are likely to be sufficiently interesting to be worth checking the code, but it's probably more likely that they already have a NAICS code than that they have one in a taxonomy that we nerds make up. It might be useful to have a separate flag that says "this isn't a phish", but I see that as a separate axis from what sort of entity the sender is. Or maybe any entity that's well enough identified to assign an organization code is by definition not a phish. R's, John From nsb@guppylake.com Mon Aug 23 05:19:59 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 0F7933A69A0 for ; Mon, 23 Aug 2010 05:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 lK9CruDyp9EP for ; Mon, 23 Aug 2010 05:19:57 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 400263A683C for ; Mon, 23 Aug 2010 05:19:57 -0700 (PDT) Received: from [108.120.7.60] (helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OnWDf-0007De-CO; Mon, 23 Aug 2010 08:33:44 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <20100823023536.30581.qmail@joyce.lan> Date: Mon, 23 Aug 2010 08:20:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823023536.30581.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] Why Industry codes? Why not reputation-aspect codes? 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, 23 Aug 2010 12:19:59 -0000 Well, my bottom line remains the same: If we want a half dozen or so = categories of institutional descriptions, do we really need to achieve = this by buying in to a taxonomy like NAICS that gives us thousands of = categories we don't want? That's the appeal to me of itemizing threats = instead -- we would confine ourselves to the things we actually care = about. I'm open to other ways of achieving that, but I'm really = skittish about adopting a big taxonomy (let alone one outside our = control) if we don't need 99% of it. -- Nathaniel PS -- I think "we nerds" are arguably the *best* people to itemize types = of threats, if not to define categories of enterprises. -- nsb On Aug 22, 2010, at 10:35 PM, John Levine wrote: >> I'm guessing that the desire for industry codes is really motivated = by a >> few specific use cases that might just as well be handled by a threat >> taxonomy. >=20 > I don't think so. Banks are a somewhat unusual case in that they tend > to be phish targets, and that in most countries they are regulated by > the government so it is possible to get a definitive list of the > genuine banks. (Yes, there are arcane corner cases. A reputation > system does not have to cover the entire universe, so it doesn't > matter.) I want to know is "this is a bank", not "this is an entity > that has not been observed to send bank phishes." If I know mail is > really from a bank, I might want to deliver it even if it smells > spammy since the potential damage of doing so is low. Note that a > rather coarse taxonomy is fine here, it's unlikely to be useful to > know the difference among the zillion types of central European banks > that Stephen mentioned. >=20 > I'm not sure what other categories are likely to be sufficiently > interesting to be worth checking the code, but it's probably more > likely that they already have a NAICS code than that they have one > in a taxonomy that we nerds make up. >=20 > It might be useful to have a separate flag that says "this isn't a > phish", but I see that as a separate axis from what sort of entity the > sender is. Or maybe any entity that's well enough identified to = assign > an organization code is by definition not a phish. >=20 > R's, > John From johnl@iecc.com Mon Aug 23 05:24:44 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 76DBE3A683C for ; Mon, 23 Aug 2010 05:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.909 X-Spam-Level: X-Spam-Status: No, score=-109.909 tagged_above=-999 required=5 tests=[AWL=1.290, 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 ewHE11q9O7n9 for ; Mon, 23 Aug 2010 05:24:43 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 0793B3A6A12 for ; Mon, 23 Aug 2010 05:24:42 -0700 (PDT) Received: (qmail 85626 invoked from network); 23 Aug 2010 12:25:15 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent:cleverness; s=k1008; bh=aN3ka3n2XGy2Ky4uj4auOa7pX+B0XL0jdOWny8BkSZs=; b=ycqf486Ot9/8epst+SsLMyeQXaHZGrtha4YC9BThD5DMinuGQV8abz1AciVGYFVUHlvsKqWqLKorFzg+ijDAL+mu+CYYVMQ6nPgb4kLw6Rq/mNaLO4fYyEDLtmNkqet2Qun9dFLjloJg+il0A14bA9ux67uKwlTC3Tqun5tSMMw= Received: (ofmipd 64.57.183.62) with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Aug 2010 12:24:53 -0000 Date: 23 Aug 2010 08:25:10 -0400 Message-ID: From: "John R. Levine" To: "Nathaniel Borenstein" In-Reply-To: References: <20100823023536.30581.qmail@joyce.lan> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] Why Industry codes? Why not reputation-aspect codes? 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, 23 Aug 2010 12:24:44 -0000 > Well, my bottom line remains the same: If we want a half dozen or so > categories of institutional descriptions, do we really need to achieve > this by buying in to a taxonomy like NAICS that gives us thousands of > categories we don't want? Since we have very little experience doing this, I dunno. But at least as a strawman, NAICS has two practical advantages. One is that the codes are of variable length, and if it turns out that a coarse taxonomy is indeed adequate, we can just look at the first two or three digits. The other is that it actually exists and gives us something we can use for experiments. > PS -- I think "we nerds" are arguably the *best* people to itemize types > of threats, if not to define categories of enterprises. -- nsb Sure. We know way more about online threats than we do about categories of organizations. R's, John From dotis@mail-abuse.org Mon Aug 23 13:41:19 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 A60CB3A6AE5 for ; Mon, 23 Aug 2010 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.011 X-Spam-Level: X-Spam-Status: No, score=-105.011 tagged_above=-999 required=5 tests=[AWL=-1.012, BAYES_50=0.001, 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 peD7eCZXt-CH for ; Mon, 23 Aug 2010 13:41:18 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id E85903A6B0E for ; Mon, 23 Aug 2010 13:40:58 -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 8AA33A9458C for ; Mon, 23 Aug 2010 20:41:26 +0000 (UTC) Message-ID: <4C72DCF6.40108@mail-abuse.org> Date: Mon, 23 Aug 2010 13:41:26 -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: <20100823023536.30581.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Why Industry codes? Why not reputation-aspect codes? 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, 23 Aug 2010 20:41:19 -0000 On 8/23/10 5:25 AM, John R. Levine wrote: >> Well, my bottom line remains the same: If we want a half dozen or so >> categories of institutional descriptions, do we really need to >> achieve this by buying in to a taxonomy like NAICS that gives us >> thousands of categories we don't want? > Since we have very little experience doing this, I dunno. But at > least as a strawman, NAICS has two practical advantages. One is that > the codes are of variable length, and if it turns out that a coarse > taxonomy is indeed adequate, we can just look at the first two or > three digits. The other is that it actually exists and gives us > something we can use for experiments. John, I agree with Nathaniel. NAICS is not concise enough. Its thousands of categories is not representative of a practical list. Is the two digit category of "52 Finance and Insurance" sufficient? After all, "522 Credit Intermediation and Related Activities" does not seem to be something better understood by those maintaining email acceptance criteria. In reality, a useful category could be whether a domain exchanges "commerce with sensitive information" likely to become a phishing target. By constraining the number of categories asserted with a flag bit, this allows simultaneous categories. Such as "commerce recognized by government agencies" could be added to Finance and Insurance, or to Public Administration (fire, police, etc.). bit 0 Agriculture, Forestry, Fishing and Hunting bit 1 Mining, Quarrying, and Oil and Gas Extraction bit 2 Utilities, bit 3 Construction, bit 4 Manufacturing, bit 5 Wholesale Trade, bit 6 Retail Trade, bit 7 Transportation and Warehousing, bit 8 Information, bit 9 Finance and Insurance bit 10 Real Estate, Rental and Leasing bit 11 Professional, Scientific and Technical Services, bit 12 Management of Companies and Enterprises, bit 13 Administrative and Support and Waste Management and Remediation Services bit 14 Educational Services, bit 16 Health Care and Social Assistance, bit 17 Arts, Entertainment, and Recreation, bit 18 Accommodation and Food Services, bit 19 Other Services (except Public) bit 20 Public Administration bit 21 Verifies Subscriptions bit 22 Handles Sensitive Transactions bit 23 Governmental domain recognition bit 24 Bonded or Insured bit 25 Open Proxy bit 26 Open Relay bit 27 Originating Identities Not Checked bit 28 Bulk Solicits Without Subscription bit 29 Cryptographically Authenticates >> PS -- I think "we nerds" are arguably the *best* people to itemize >> types of threats, if not to define categories of enterprises. -- nsb > Sure. We know way more about online threats than we do about > categories of organizations. Which suggests that these efforts should be constrained to bits >20? -Doug From nsb@guppylake.com Tue Aug 24 06:42:35 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 85B123A69DC for ; Tue, 24 Aug 2010 06:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001] 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 45w0oLW62PIp for ; Tue, 24 Aug 2010 06:42:33 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id CB6C33A69DA for ; Tue, 24 Aug 2010 06:42:32 -0700 (PDT) Received: from c-68-42-72-22.hsd1.mi.comcast.net ([68.42.72.22] helo=[192.168.0.9]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ontz9-0006ph-U5; Tue, 24 Aug 2010 09:56:21 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4C72DCF6.40108@mail-abuse.org> Date: Tue, 24 Aug 2010 09:42:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100823023536.30581.qmail@joyce.lan> <4C72DCF6.40108@mail-abuse.org> To: Douglas Otis 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] Why Industry codes? Why not reputation-aspect codes? 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, 24 Aug 2010 13:42:35 -0000 Perhaps we could at least take a first stab at a threat taxonomy, to see = if what we end up with is more or less appealing than a NAICS type of = taxonomy? (And of course they're not mutually exclusive, either, but = I'd rather simplify than make this more complex.) I think there's a lot to be said for a few, highly logical top-level = categories, with a possible proliferation of subcategories. Off the top = of my head, here are four categories of things I'd like to know whether = or not a domain is reputed to be guilty of, along with a sampling of = possible subcategories -- sending unsolicited bulk email (subcategories might include = fraud) -- sending email with false/deceptive sender information = (subcategory: claiming falsely to be a trusted institution, perhaps with = financial and other sub-subcategories) -- sending active malware content (several subcategories = possible) -- failure to maintain best practices for email servers = (possible subcategories for open relays, Non-responsiveness (or = unacceptably slow response) to abuse reports, etc.) I'm sure there are others, but this seems like a very actionable kind of = information, which is what I think we need. -- Nathaniel On Aug 23, 2010, at 4:41 PM, Douglas Otis wrote: > On 8/23/10 5:25 AM, John R. Levine wrote: >>> Well, my bottom line remains the same: If we want a half dozen or = so categories of institutional descriptions, do we really need to = achieve this by buying in to a taxonomy like NAICS that gives us = thousands of categories we don't want? >> Since we have very little experience doing this, I dunno. But at = least as a strawman, NAICS has two practical advantages. One is that = the codes are of variable length, and if it turns out that a coarse = taxonomy is indeed adequate, we can just look at the first two or three = digits. The other is that it actually exists and gives us something we = can use for experiments. > John, >=20 > I agree with Nathaniel. NAICS is not concise enough. Its thousands = of categories is not representative of a practical list. Is the two = digit category of "52 Finance and Insurance" sufficient? After all, = "522 Credit Intermediation and Related Activities" does not seem to be = something better understood by those maintaining email acceptance = criteria. In reality, a useful category could be whether a domain = exchanges "commerce with sensitive information" likely to become a = phishing target. By constraining the number of categories asserted with = a flag bit, this allows simultaneous categories. Such as "commerce = recognized by government agencies" could be added to Finance and = Insurance, or to Public Administration (fire, police, etc.). >=20 > bit 0 Agriculture, Forestry, Fishing and Hunting > bit 1 Mining, Quarrying, and Oil and Gas Extraction > bit 2 Utilities, > bit 3 Construction, > bit 4 Manufacturing, > bit 5 Wholesale Trade, > bit 6 Retail Trade, > bit 7 Transportation and Warehousing, > bit 8 Information, > bit 9 Finance and Insurance > bit 10 Real Estate, Rental and Leasing > bit 11 Professional, Scientific and Technical Services, > bit 12 Management of Companies and Enterprises, > bit 13 Administrative and Support and Waste Management and Remediation = Services > bit 14 Educational Services, > bit 16 Health Care and Social Assistance, > bit 17 Arts, Entertainment, and Recreation, > bit 18 Accommodation and Food Services, > bit 19 Other Services (except Public) > bit 20 Public Administration >=20 > bit 21 Verifies Subscriptions > bit 22 Handles Sensitive Transactions > bit 23 Governmental domain recognition > bit 24 Bonded or Insured > bit 25 Open Proxy > bit 26 Open Relay > bit 27 Originating Identities Not Checked > bit 28 Bulk Solicits Without Subscription > bit 29 Cryptographically Authenticates >=20 >>> PS -- I think "we nerds" are arguably the *best* people to itemize = types of threats, if not to define categories of enterprises. -- nsb >> Sure. We know way more about online threats than we do about = categories of organizations. > Which suggests that these efforts should be constrained to bits >20? >=20 > -Doug >=20 >=20 >=20 > _______________________________________________ > domainrep mailing list > domainrep@ietf.org > https://www.ietf.org/mailman/listinfo/domainrep From johnl@iecc.com Tue Aug 24 08:11: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 36D1F3A67A5 for ; Tue, 24 Aug 2010 08:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.925 X-Spam-Level: X-Spam-Status: No, score=-109.925 tagged_above=-999 required=5 tests=[AWL=1.274, 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 aPj6opCbyH48 for ; Tue, 24 Aug 2010 08:11:40 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by core3.amsl.com (Postfix) with ESMTP id 766603A69F2 for ; Tue, 24 Aug 2010 08:11:40 -0700 (PDT) Received: (qmail 14799 invoked from network); 24 Aug 2010 15:12:12 -0000 Received: from mail1.iecc.com (64.57.183.56) by mail1.iecc.com with QMQP; 24 Aug 2010 15:12:12 -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=k1008; olt=johnl@user.iecc.com; bh=cIm5Rk9OCdaIMC7AQ3Kl8JICyl+q2P/xYIUS4dyie4Y=; b=U+Qsz8Qa2iP5zDUMThNwZ4iYN2w41NtzNztlyT0IkRWekVpIDgwrlac/SuqAM6G43nv/ja7xcZYrbWV2d5+fboofJcsV/vQJ2toCS21h6RNdmcW0dHGMJBsbWaSyLwLm3Lr+14+sikLp06P6N4zInHmH5y2Qw+IvM2gz885VtJs= Date: 24 Aug 2010 15:12:07 -0000 Message-ID: <20100824151207.63799.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] Why Industry codes? Why not reputation-aspect codes? 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, 24 Aug 2010 15:11:42 -0000 >Perhaps we could at least take a first stab at a threat taxonomy, to >see if what we end up with is more or less appealing than a NAICS >type of taxonomy? 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. >be guilty of, along with a sampling of possible subcategories > > -- sending unsolicited bulk email (subcategories might include fraud) Huh? Bulk and fraud are separate. You can have either without the other. > -- sending email with false/deceptive sender information (subcategory: claiming >falsely to be a trusted institution, perhaps with financial and other >sub-subcategories) I see those as functionally separate; fraud to sneak unwanted but otherwise harmless content into inboxes (Gevalia type spam) vs. fraud to enable crime. > -- sending active malware content (several subcategories possible) > -- failure to maintain best practices for email servers (possible subcategories >for open relays, Non-responsiveness (or unacceptably slow response) to abuse >reports, etc.) Beyond concrete items like relaying mail for stranges, that seems too subjective to be useful. R's, John From jdfalk-lists@cybernothing.org Tue Aug 24 09:43:14 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 0B43E3A6BB7 for ; Tue, 24 Aug 2010 09:43:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.317 X-Spam-Level: X-Spam-Status: No, score=-5.317 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_40=-0.185, 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 M9ucoYh-So4n for ; Tue, 24 Aug 2010 09:42:31 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0B5D23A6B9F for ; Tue, 24 Aug 2010 09:39:50 -0700 (PDT) Received: from [192.168.11.33] (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 o7OGeBhX029629 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 24 Aug 2010 09:40:13 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7OGeBhX029629 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282668013; bh=VVxm5CsCIdYFhHzjFG/SL7z3yl2WXPuuvoVrqYKOH 1s=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=ZuI0UboRrG1kEPVm 7dzjdei23hvobgybWA76TfAHFrNQog6vqsHUHOjUD8SCsbAIw478sBHCjsC79yDXrBU 1ILsoNPs/+AxzepmRCVUQbjlRMWT5DtCjK5yrNkzUc+3+dObeG6asyKCbbJLHJTFXB6 o0xXl5oaLs4BSDDPu7hNQ= References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> <4C6D729F.1080504@mail-abuse.org> <4C6FA44C.6010100@tana.it> In-Reply-To: <4C6FA44C.6010100@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <8F17D477-4E8D-40DE-9C01-FA05071A9B2B@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 24 Aug 2010 09:40:10 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] Industry taxonomies such as NAICS (was Re: A sketch of a small query reputation system) 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, 24 Aug 2010 16:43:14 -0000 On Aug 21, 2010, at 3:02 AM, Alessandro Vesely wrote: > However, negative contributions to a domain's reputation should be = exceptional means to reproach that domain's admins, e.g. in case they = fail to properly handle an incident. That's human policy -- a value judgement, not a technical standard. >> Would you be happy having your DOMAIN blocked by a service that is = not obligated to offer any authenticated evidence justifying the = negative ratings given for your DOMAIN? The magnitude of a rating is = not important. However, the range of values representing negative = reputations, and values that represents an "unknown" reputation MUST be = specified. >=20 > There is no point in setting global negative values for a domain's = reputation. Persistent abusers will just change to new domain names. = Reputation must reflect good behavior. That's also a value judgement. A fully open, universally applicable standard will also work for = implementors whose value judgements we might personally disagree with. From jdfalk-lists@cybernothing.org Tue Aug 24 09:43: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 E60D93A6B27 for ; Tue, 24 Aug 2010 09:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 w+J+ywtWwsq2 for ; Tue, 24 Aug 2010 09:43:32 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 572753A6B9C for ; Tue, 24 Aug 2010 09:43:23 -0700 (PDT) Received: from [192.168.11.33] (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 o7OGhsp9029683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 24 Aug 2010 09:43:56 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7OGhsp9029683 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282668236; bh=FdVvUuxy5yNfQwvtjxBidtD/TJlzdZJgXKZfqVheI 1g=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=bhuQ5oTUp8EieS+B AMIDRw2Tv38YXriRFO1wQjhhiQdbxy5LnwksKAsjo5Uc+eyYnO4hxg7xDBjpvjdMbnh wWwy0d7KwlSUkstE+Zx3vdB/P3tv5m0Y/nxkKcmLWWu0q4PoFufB4bIbqYKezc4yoNe rjKCYM90vlYXqqfKpx67Q= References: <20100823023536.30581.qmail@joyce.lan> <4C72DCF6.40108@mail-abuse.org> In-Reply-To: Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <749D82AD-8308-4135-AFD2-6C0E05BF65C8@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 24 Aug 2010 09:43:53 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] Why Industry codes? Why not reputation-aspect codes? 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, 24 Aug 2010 16:43:33 -0000 On Aug 24, 2010, at 6:42 AM, Nathaniel Borenstein wrote: > Perhaps we could at least take a first stab at a threat taxonomy, to = see if what we end up with is more or less appealing than a NAICS type = of taxonomy? (And of course they're not mutually exclusive, either, but = I'd rather simplify than make this more complex.) We did that for ARF -- it was a loose taxonomy of things one might = complain about, which is very similar. Even with pressure to keep the = list small, we ended up removing nearly all of the types because nobody = used them. > I think there's a lot to be said for a few, highly logical top-level = categories, with a possible proliferation of subcategories. Off the top = of my head, here are four categories of things I'd like to know whether = or not a domain is reputed to be guilty of, along with a sampling of = possible subcategories >=20 > -- sending unsolicited bulk email (subcategories might include = fraud) > -- sending email with false/deceptive sender information = (subcategory: claiming falsely to be a trusted institution, perhaps with = financial and other sub-subcategories) > -- sending active malware content (several subcategories = possible) > -- failure to maintain best practices for email servers = (possible subcategories for open relays, Non-responsiveness (or = unacceptably slow response) to abuse reports, etc.) Say we've got a DKIM d=3D domain in each of these categories. How/why = would an MTA treat them differently? From vesely@tana.it Tue Aug 24 11:08:28 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 0BCAA3A687F for ; Tue, 24 Aug 2010 11:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_50=0.001, 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 8ECDAwXW4H4e for ; Tue, 24 Aug 2010 11:08:26 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 92B0E3A6837 for ; Tue, 24 Aug 2010 11:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282673334; bh=NqWyD3ZqUV8HdqsMiUGSj3a+sRwwbgmXiRXvM/ZzK0w=; l=1302; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YgWqOx3bUHxGSzbD6zz7/tHLBVk1sPBAzscMmc0deLuZ3XTVLDAsZEeuSMJRMsoYU LeIBxhzogMM55meYvKRdevrP9jrXVu7RmVKa7XC0mwMx1ul0zaqsaGalzJRojUwviL BszG2kdtO881qiis7aXActOWvljmsM2ZZm8W5vOI= Received: from 1-38-169-90.live.vodafone.in (93-32-180-175.ip34.fastwebnet.it [93.32.180.175]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 24 Aug 2010 20:08:54 +0200 id 00000000005DC033.000000004C740AB6.00007F3C Message-ID: <4C740AB6.3090509@tana.it> Date: Tue, 24 Aug 2010 20:08:54 +0200 From: Alessandro Vesely User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: domainrep@ietf.org References: <20100813172212.80598.qmail@joyce.lan> <0BC8B740-9B39-494C-93FB-61A436207CC3@guppylake.com> <06589D45-81B3-4821-A17F-AE09D9CF371D@guppylake.com> <4C6910DB.1050202@cs.tcd.ie> <4C692051.8070006@tana.it> <20100816215255.GB86057@shinkuro.com> <4C69CF37.6060608@mail-abuse.org> <20100817145750.GC88824@shinkuro.com> <4C6AE282.1070907@mail-abuse.org> <4C6BCCB6.8090008@tana.it> <4C6C1F79.9000201@mail-abuse.org> <4C6CFA50.4050701@tana.it> <4C6D729F.1080504@mail-abuse.org> <4C6FA44C.6010100@tana.it> <8F17D477-4E8D-40DE-9C01-FA05071A9B2B@cybernothing.org> In-Reply-To: <8F17D477-4E8D-40DE-9C01-FA05071A9B2B@cybernothing.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Positive reputation, was Industry taxonomies 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, 24 Aug 2010 18:08:28 -0000 J.D. Falk wrote: > On Aug 21, 2010, at 3:02 AM, Alessandro Vesely wrote: >> There is no point in setting global negative values for a >> domain's reputation. Persistent abusers will just change to >> new domain names. Reputation must reflect good behavior. > > That's also a value judgement. A human or site policy might state that, say, a score of 4.5 is sufficient to reject or discard messages from a domain whose trust rating is less than 0.1. Likewise, a policy may state that messages will be rejected from a domain flagged with the value (taken from Nataniel's threat taxonomy) of "sending unsolicited bulk email". Even if both examples express value judgements, their underlying conceptual models are very different. The first example presumes that domains' reputations are adjusted according to behavior, so as to measure their cooperativeness. The second example, by setting negative values, implies the whack-a-mole model. > A fully open, universally applicable standard will also work for > implementors whose value judgements we might personally disagree > with. Fully agreed. Yet, saying that reputations hold positive values --much like distances or weights-- is not a question of opinions: it is a modeling decision. Shall we make it? From R.E.Sonneveld@sonnection.nl Thu Aug 26 06:58: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 21E433A687B for ; Thu, 26 Aug 2010 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.44 X-Spam-Level: X-Spam-Status: No, score=-3.44 tagged_above=-999 required=5 tests=[AWL=-1.936, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 K4rgG+BtpN+d for ; Thu, 26 Aug 2010 06:58:02 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id F38FD3A687D for ; Thu, 26 Aug 2010 06:57:59 -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 <0L7R0014TITI3V00@lion.sonnection.nl> for domainrep@ietf.org; Thu, 26 Aug 2010 15:58:31 +0200 (CEST) Message-id: <4C767306.9080708@sonnection.nl> Date: Thu, 26 Aug 2010 15:58:30 +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 References: <20100823023536.30581.qmail@joyce.lan> <4C72DCF6.40108@mail-abuse.org> <749D82AD-8308-4135-AFD2-6C0E05BF65C8@cybernothing.org> In-reply-to: <749D82AD-8308-4135-AFD2-6C0E05BF65C8@cybernothing.org> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1282831111; bh=JePpIeGi8oIo6tKQmjeUnfP+Vd8AQlrvf9FEY08UTHg=; h=Message-ID:Date:From:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WeIGD6Q90gHBO0E6rk8YuLe8rHBz5jfFD8QQKB+4qUuePQgJC6wotbL+mgf31faw+ ypxoWZTIyNZd/0sb4RPQe/i/Vy4WdrC9rlH9Xpmj87ZPRpmTqlQ6hGxj8o2QIoIT0b KB/mcOFzLXDj5P6GNVyaZSenZiCkJU7UaipA9aks= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7R0014TITI3V00 Subject: Re: [domainrep] Why Industry codes? Why not reputation-aspect codes? 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, 26 Aug 2010 13:58:04 -0000 On 08/24/2010 06:43 PM, J.D. Falk wrote: > On Aug 24, 2010, at 6:42 AM, Nathaniel Borenstein wrote: > >> Perhaps we could at least take a first stab at a threat taxonomy, to see if what we end up with is more or less appealing than a NAICS type of taxonomy? (And of course they're not mutually exclusive, either, but I'd rather simplify than make this more complex.) > We did that for ARF -- it was a loose taxonomy of things one might complain about, which is very similar. Even with pressure to keep the list small, we ended up removing nearly all of the types because nobody used them. > >> I think there's a lot to be said for a few, highly logical top-level categories, with a possible proliferation of subcategories. Off the top of my head, here are four categories of things I'd like to know whether or not a domain is reputed to be guilty of, along with a sampling of possible subcategories >> >> -- sending unsolicited bulk email (subcategories might include fraud) >> -- sending email with false/deceptive sender information (subcategory: claiming falsely to be a trusted institution, perhaps with financial and other sub-subcategories) >> -- sending active malware content (several subcategories possible) >> -- failure to maintain best practices for email servers (possible subcategories for open relays, Non-responsiveness (or unacceptably slow response) to abuse reports, etc.) > Say we've got a DKIM d= domain in each of these categories. How/why would an MTA treat them differently? I'd like to chime in here, as I'm currently trying to assemble information circulated within this group to write a draft. I have not seen a reply to the questions of JD and it makes me wonder whether this question might be hard to answer? I have thought about this and I'd like to make two remarks: 1. I have absolutely no problem with the proposal of Nathaniel, but when we start talking about subcategories of subcategories, in my view the definition of such a taxonomy should be part of the XML variant of the reputation format. I'm referring here to the original thread started by John about small domain reputations (small query reputation system) and large domain reputations (large query reputation system?). I think the conclusion was that there is room for multiple types of query reputation systems and associated transports. The first two identified were: tag=value format + DNS transport XML format + SOAP/HTTP transport 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. If someone thinks it fits in a small query system, then please suggest how the sub-sub-categories should be addressed. 2. talking about a threat taxonomy, I'd like to suggest to change the definition of the various categories, that the category name does not imply only negative reputation. For example: I can imagine that there are organizations which are interested to know whether a sending domain has a positive reputation in the area of malware: companies like Sophos and organizations like CERT get a positive reputation here. Of course I know that it's too simple to just trust all mail from such organizations, but it's possible that their positive reputation can be used as one of many criteria to judge, for the Domain Reputation Assessor. So values can range for example from -10 to +10, instead of from 0 to -10. /rolf From dotis@mail-abuse.org Thu Aug 26 14:54: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 35FCD3A691A for ; Thu, 26 Aug 2010 14:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.709 X-Spam-Level: X-Spam-Status: No, score=-104.709 tagged_above=-999 required=5 tests=[AWL=-1.310, BAYES_50=0.001, J_CHICKENPOX_35=0.6, 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 rmXbwivdIH-y for ; Thu, 26 Aug 2010 14:54:40 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id AFE203A68A7 for ; Thu, 26 Aug 2010 14:54:40 -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 08DD2A94825 for ; Thu, 26 Aug 2010 21:55:09 +0000 (UTC) Message-ID: <4C76E2BD.4040609@mail-abuse.org> Date: Thu, 26 Aug 2010 14:55:09 -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: <20100823023536.30581.qmail@joyce.lan> <4C72DCF6.40108@mail-abuse.org> <749D82AD-8308-4135-AFD2-6C0E05BF65C8@cybernothing.org> <4C767306.9080708@sonnection.nl> In-Reply-To: <4C767306.9080708@sonnection.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Why Industry codes? Why not reputation-aspect codes? 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, 26 Aug 2010 21:54:42 -0000 On 8/26/10 6:58 AM, Rolf E. Sonneveld wrote: > On 08/24/2010 06:43 PM, J.D. Falk wrote: >> On Aug 24, 2010, at 6:42 AM, Nathaniel Borenstein wrote: >>> Perhaps we could at least take a first stab at a threat taxonomy, to >>> see if what we end up with is more or less appealing than a NAICS >>> type of taxonomy? (And of course they're not mutually exclusive, >>> either, but I'd rather simplify than make this more complex.) >> We did that for ARF -- it was a loose taxonomy of things one might >> complain about, which is very similar. Even with pressure to keep >> the list small, we ended up removing nearly all of the types because >> nobody used them. The MARF (or ARF) RFC only relates to email and does not categorize reported abuse, such as whether it involves security related issues which could include malware or phishing attempts. Instead, reporting depends upon the message as being self explanatory. This means MARF offers little in the way of useful categories, particularly when even the Reported-URI or Reported-Domain are ill defined. For URI: ,--- Furthermore, it is outside the scope of this standard whether the data carried in this field implies any additional information. Implementors may negotiate their own agreements surrounding the interpretation of this data. '--- For Domain: ,--- It is unspecified how the report generator determines this information, and thus the report receiver cannot be certain how it was chosen. It is often used as a means of suggesting to the report receiver how this report might be handled. '--- When IPv6 email acceptance depends upon cryptographic host name confirmations for systems relaying messages, this format will need domain to be better defined. See: http://www.iana.org/assignments/marf-parameters/marf-parameters.xhtml >>> I think there's a lot to be said for a few, highly logical top-level >>> categories, with a possible proliferation of subcategories. Off the >>> top of my head, here are four categories of things I'd like to know >>> whether or not a domain is reputed to be guilty of, along with a >>> sampling of possible subcategories >>> >>> -- sending unsolicited bulk email (subcategories might include >>> fraud) >>> -- sending email with false/deceptive sender information >>> (subcategory: claiming falsely to be a trusted institution, perhaps >>> with financial and other sub-subcategories) >>> -- sending active malware content (several subcategories possible) >>> -- failure to maintain best practices for email servers >>> (possible subcategories for open relays, Non-responsiveness (or >>> unacceptably slow response) to abuse reports, etc.) >> Say we've got a DKIM d= domain in each of these categories. How/why >> would an MTA treat them differently? > > I'd like to chime in here, as I'm currently trying to assemble > information circulated within this group to write a draft. I have not > seen a reply to the questions of JD and it makes me wonder whether > this question might be hard to answer? > > I have thought about this and I'd like to make two remarks: > > 1. I have absolutely no problem with the proposal of Nathaniel, but > when we start talking about subcategories of subcategories, in my view > the definition of such a taxonomy should be part of the XML variant of > the reputation format. I'm referring here to the original thread > started by John about small domain reputations (small query reputation > system) and large domain reputations (large query reputation system?). > I think the conclusion was that there is room for multiple types of > query reputation systems and associated transports. The first two > identified were: > > tag=value format + DNS transport This type of structure is unsuitable for dealing with domain or URI related information without a definition of registration domains, such as TLDs, or SLDs, to only permit the next level for initial queries, or a scheme where the entire database is routinely transferred in some incrementally updating form. Don't limit "small scale" to only using DNS. A small scale service based upon a simple query answer structure should be considered appropriate only for source IPv4 address reputations. Domain, URI, nor IPv6 will scale without bounding the initial query which then requires subsequent queries to complete the transaction when using DNS. The additional round trips will likely become problematic. > XML format + SOAP/HTTP transport This type of structure is unsuitable for dealing with domain or URI related information without a strategy to cache and distribute the data, and a means to protect servers from abuse. This is a real design challenge. > 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. If someone thinks it fits in a small query system, then please > suggest how the sub-sub-categories should be addressed. 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 type Required. ENUM. Classifies the malicious activity into incident categories. The permitted values are shown below. The default value is "other". 1. admin. Administrative privileges were attempted. 2. dos. A denial of service was attempted. 3. file. An action that impacts the integrity of a file or database was attempted. 4. info-leak. An attempt was made to exfiltrate information. 5. misconfiguration. An attempt was made to exploit a mis- configuration in a system. 6. policy. Activity violating site's policy was attempted. 7. recon. Reconnaissance activity was attempted. 8. social-engineering. A social engineering attack was attempted. 9. user. User privileges were attempted. 10. unknown. The classification of this activity is unknown. 11. ext-value. An escape value used to extend this attribute. See Section 5.1. > 2. talking about a threat taxonomy, I'd like to suggest to change the > definition of the various categories, that the category name does not > imply only negative reputation. For example: I can imagine that there > are organizations which are interested to know whether a sending > domain has a positive reputation in the area of malware: companies > like Sophos and organizations like CERT get a positive reputation here. Sorry, but no domain is immune. Any domain can be compromised, be it little or large. Some may decide to ignore a significant level of abuse being emitted whenever the domain is considered too large, and likely to create support issues when normal commerce becomes disrupted. > Of course I know that it's too simple to just trust all mail from such > organizations, but it's possible that their positive reputation can be > used as one of many criteria to judge, for the Domain Reputation > Assessor. So values can range for example from -10 to +10, instead of > from 0 to -10. Do you mean for the small scale solution instead of values 0 to 10? Perhaps this could be +127 to -128 using an address octet as a signed 2's complement number, for example. Using signed 2's complements for +100 to -100 would be 0x64 to 0x9C, where 0 would be 0. -Doug From vesely@tana.it Fri Aug 27 03:18: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 CFFE83A6B8F for ; Fri, 27 Aug 2010 03:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.663, BAYES_50=0.001, 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 EvABuqxEl6q2 for ; Fri, 27 Aug 2010 03:18:29 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6609C3A6BA7 for ; Fri, 27 Aug 2010 03:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282904340; bh=kbeMWJVGMQVy5VML9fbdYaMsdXGRe+sQNspW6odtcHI=; l=2426; h=Message-ID:Date:From:MIME-Version:To:Content-Transfer-Encoding; b=TTP6WQp3D7w93+YEn5Q1+fdMoPK8Xj5I8Pb8cFI9H+gCP9GFBrQow1Ifgzjlohq5k y1GkKOaShhk85RCQNb8Mvb/VIrJdPAE235ergweA47Q2tMvQ+JkD+kAtUxmENhd0Lh /9UWZnYLrnagJ5LbQuj1SoFjuc19zjtQlFr3TTAs= 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; Fri, 27 Aug 2010 12:19:00 +0200 id 00000000005DC035.000000004C779114.00002082 Message-ID: <4C779114.3050109@tana.it> Date: Fri, 27 Aug 2010 12:19:00 +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 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [domainrep] 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: Fri, 27 Aug 2010 10:18:30 -0000 I think it may help understanding if we spell what we mean by a Domain Reputation System (DRS). One way to describe a conceptual model is to define a list of features, so that we can then poll each one. Here's a tentative list, please add/change as appropriate. *Small query* Paramount simple properties or a domain reputation can be retrieved by short (UDP) DNS queries. *Large query* Complete raw data about a domain can be retrieved via HTTP in the form of an XML scheme. *Taxonomy* Each domain's activity is described by a code (to be determined). Possible uses of the code include estimating the likelihood of phishing, transactional mail, ad campaigns for 3rd parties, content by anonymous/unidentifiable users, liability for abusive behavior. (More?) *Application specific quality* A domain reputation is affected by its behavior. Email, web, chat, and other apps (which ones?) contribute separate scores. *Domains are ADMDs* When we talk of /domain/ reputation we mean the ADMD, not the specific servers. (While DKIM exhibits a "d=" tag that perfectly suits this purpose, I don't see the equivalent in other apps or SPF.) *Private implementation* Domain reputation data is collected and maintained by private organizations using their own "secret sauce". Clients may choose one or more DRS, based on their preferences. *Web of trust* Domain reputation data are collected by a number of participating servers. The participating domains are linked to one another in a directed graph with weights, thereby defining a web of trust. Maintenance of data is largely automatic, based on incident reports, abuse reports, and the like. *MARF interface* The trusted entity that provides reputation data for a given domain is among the targets of forwarded abuse reports. DRS are a well-defined implementation of MARF, in the sense that implementation-specific fields like Reported-URI and Reported-Domain bear a well defined meaning, homogeneous across all DRS servers. *IODEF interface* Incident reports received by network providers' CSIRTs should affect a domain's reputation too, in case they can be unambiguously attributed to a domain. *DNSBL interface* Should these contribute directly to domains' reputation? As for (some) incident reports, this would require a standard rule to get the domain responsible for a given IP. From jdfalk-lists@cybernothing.org Fri Aug 27 13:56:11 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 B85E43A68F3 for ; Fri, 27 Aug 2010 13:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqzpiTRcoJud for ; Fri, 27 Aug 2010 13:56:10 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 7E2363A67B5 for ; Fri, 27 Aug 2010 13:56:10 -0700 (PDT) Received: from rpco-ralbe620.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RKueUv027459 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 27 Aug 2010 13:56:42 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7RKueUv027459 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282942602; bh=IgU6BhGX/kpxEnNEnHzdFUL7f1ryMmatBzav8PNG1 LQ=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=hV6djX++8bjA5dES RYlbu7psG/fgEH5HfWhsxDiG3wYMT8QCvLsY/4AXu3L/bSOGCKKY3WjJilsVvLqGOOd ypROIhJ3c1f9DvubEnbI181qdDxNtPSoHhIbx/6+1DOUC6xnnG1K5ZK6CQlOp5KOa3I iUD8MgLmuwTFHHS345vR4= References: <20100823023536.30581.qmail@joyce.lan> <4C72DCF6.40108@mail-abuse.org> <749D82AD-8308-4135-AFD2-6C0E05BF65C8@cybernothing.org> <4C767306.9080708@sonnection.nl> In-Reply-To: <4C767306.9080708@sonnection.nl> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <1F940F47-9268-42C7-B139-E5EB0C8F5B5C@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Fri, 27 Aug 2010 13:56:34 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] Why Industry codes? Why not reputation-aspect codes? 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: Fri, 27 Aug 2010 20:56:11 -0000 (as a participant) On Aug 26, 2010, at 6:58 AM, Rolf E. Sonneveld wrote: >>> -- sending unsolicited bulk email (subcategories might include = fraud) >>> -- sending email with false/deceptive sender information = (subcategory: claiming falsely to be a trusted institution, perhaps with = financial and other sub-subcategories) >>> -- sending active malware content (several subcategories = possible) >>> -- failure to maintain best practices for email servers = (possible subcategories for open relays, Non-responsiveness (or = unacceptably slow response) to abuse reports, etc.) >> Say we've got a DKIM d=3D domain in each of these categories. = How/why would an MTA treat them differently? >=20 > I'd like to chime in here, as I'm currently trying to assemble = information circulated within this group to write a draft. I have not = seen a reply to the questions of JD and it makes me wonder whether this = question might be hard to answer? I think you're right -- and part of the reason is that outside of = blacklists (rejection or temporary rejection) and whitelists (overriding = other spam filters), we as an industry don't have a lot of experience = with defining more complex policies. Lacking that experience, I think it'll continue to be difficult for us = to figure out exactly which types of information will be needed for a = complex policy. Instead, 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. From jdfalk-lists@cybernothing.org Fri Aug 27 14:02:28 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 D69E03A68F3 for ; Fri, 27 Aug 2010 14:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tEaTLwV-lyLB for ; Fri, 27 Aug 2010 14:02:27 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id C66E13A67B5 for ; Fri, 27 Aug 2010 14:02:27 -0700 (PDT) Received: from rpco-ralbe620.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RL2v5t027695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 27 Aug 2010 14:02:59 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7RL2v5t027695 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282942979; bh=n7EkFdaE+ae7K2hmdBKPqF8UtQqRpPGKYViv2hPAx b8=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=jM/GqhRi7CNQ9vCf rEwBO3KNLQmDYCCatKVHR/uBHA2WXWpwDNjlu/DEOOTh14dn86lWC37POAAYGHoc189 dDKiZj0NXfqSPnjY2BeUWmxdSc5GzrJ1praew4++UmL+hqt3gm4uDZXB45hIZmzfv4G NP5xiciWbVODU2025Qx1M= References: <4C779114.3050109@tana.it> In-Reply-To: <4C779114.3050109@tana.it> 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: Fri, 27 Aug 2010 14:02:52 -0700 To: domainrep@ietf.org X-Mailer: Apple Mail (2.1081) Subject: Re: [domainrep] 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: Fri, 27 Aug 2010 21:02:28 -0000 (as a participant) On Aug 27, 2010, at 3:19 AM, Alessandro Vesely wrote: > I think it may help understanding if we spell what we mean by a Domain = Reputation System (DRS). One way to describe a conceptual model is to = define a list of features, so that we can then poll each one. Here's a = tentative list, please add/change as appropriate. >=20 > *Small query* > Paramount simple properties or a domain reputation can be retrieved by = short (UDP) DNS queries. +1 > *Large query* > Complete raw data about a domain can be retrieved via HTTP in the form = of an XML scheme. Probably, but I'm not entirely convinced yet. > *Taxonomy* > Each domain's activity is described by a code (to be determined). = Possible uses of the code include estimating the likelihood of phishing, = transactional mail, ad campaigns for 3rd parties, content by = anonymous/unidentifiable users, liability for abusive behavior. (More?) I agree with the possible uses, but I'm still concerned that we could = argue about that list forever and never reach consensus -- and even if = we did reach consensus, we won't have predicted every possible use case. = Better, I think, to let the Reputation Providers and Reputation Clients = work that out later. > *Application specific quality* > A domain reputation is affected by its behavior. Email, web, chat, = and other apps (which ones?) contribute separate scores. +1 > *Domains are ADMDs* > When we talk of /domain/ reputation we mean the ADMD, not the specific = servers. (While DKIM exhibits a "d=3D" tag that perfectly suits this = purpose, I don't see the equivalent in other apps or SPF.) Probably +1, but I'm open to arguments to expand it. > *Private implementation* > Domain reputation data is collected and maintained by private = organizations using their own "secret sauce". Clients may choose one or = more DRS, based on their preferences. +1 > *Web of trust* > Domain reputation data are collected by a number of participating = servers. The participating domains are linked to one another in a = directed graph with weights, thereby defining a web of trust. = Maintenance of data is largely automatic, based on incident reports, = abuse reports, and the like. -1 -- this is one possible implementation, but I wouldn't want to = exclude others. > *MARF interface* > The trusted entity that provides reputation data for a given domain is = among the targets of forwarded abuse reports. DRS are a well-defined = implementation of MARF, in the sense that implementation-specific fields = like Reported-URI and Reported-Domain bear a well defined meaning, = homogeneous across all DRS servers. >=20 > *IODEF interface* > Incident reports received by network providers' CSIRTs should affect a = domain's reputation too, in case they can be unambiguously attributed to = a domain. >=20 > *DNSBL interface* > Should these contribute directly to domains' reputation? As for = (some) incident reports, this would require a standard rule to get the = domain responsible for a given IP. -3 -- these are all possible implementations, and I know the MARF and = DNSBL options are used today, but it should be left up to each = individual Reputation Provider. From jdfalk-lists@cybernothing.org Fri Aug 27 14:02:52 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 823CE3A6853 for ; Fri, 27 Aug 2010 14:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1N4kRNVxPUcW for ; Fri, 27 Aug 2010 14:02:50 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 320403A68CE for ; Fri, 27 Aug 2010 14:02:49 -0700 (PDT) Received: from rpco-ralbe620.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RL2v5u027695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 27 Aug 2010 14:03:20 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7RL2v5u027695 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1282943001; bh=rfptCLCh8YoHJoi9GBt2FASVi23Y54nWNd6xswmtw MY=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:Cc:From:Subject:Date:To; b=gvHkOwNe3Mj1i fUqHdcJXySQLy03w66t7K20a762AO/IoiXU2qEzleBzodHRIi5/L1cyikQAaV4rsMs5 Iwg/OwfECXilI0orWVD6EX7dYZDHbojl/2cGkMJqeW78cBfF0C3GHSykvc/sIEKid2T dr2JYX0w/Hl7idV2ZwAAiGys= References: <4C779114.3050109@tana.it> In-Reply-To: <4C779114.3050109@tana.it> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <091A8C81-D804-4448-AF37-E252825D6EBD@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Fri, 27 Aug 2010 14:03:20 -0700 To: Alessandro Vesely X-Mailer: Apple Mail (2.1081) Cc: domainrep@ietf.org Subject: Re: [domainrep] 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: Fri, 27 Aug 2010 21:02:52 -0000 Thanks for trying to codify these, BTW. I'm looking forward to other = replies. From dotis@mail-abuse.org Fri Aug 27 18:53: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 079EC3A6778 for ; Fri, 27 Aug 2010 18:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.996 X-Spam-Level: X-Spam-Status: No, score=-104.996 tagged_above=-999 required=5 tests=[AWL=-0.997, BAYES_50=0.001, 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 oALsAs7ulVfI for ; Fri, 27 Aug 2010 18:53:28 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id A47E33A672F for ; Fri, 27 Aug 2010 18:53:28 -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 7DFDCA9456D for ; Sat, 28 Aug 2010 01:53:54 +0000 (UTC) Message-ID: <4C786C32.6060304@mail-abuse.org> Date: Fri, 27 Aug 2010 18:53: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: <4C779114.3050109@tana.it> In-Reply-To: <4C779114.3050109@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] 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: Sat, 28 Aug 2010 01:53:30 -0000 On 8/27/10 3:19 AM, Alessandro Vesely wrote: > I think it may help understanding if we spell what we mean by a > Domain Reputation System (DRS). One way to describe a conceptual > model is to define a list of features, so that we can then poll each > one. Here's a tentative list, please add/change as appropriate. > > *Small query* Paramount simple properties or a domain reputation can > be retrieved by short (UDP) DNS queries. To handle domains lacking path components, initial queries still need their depth constrained as a defense against DDoS attacks. In other words, the query scheme should establish registrar's domains, and then only allow initial queries one level below these. Registrar domains can be safely cached over long periods, and can be uniquely identified by having a specific category. It would be good to standardize on a method for restricting results to clients subscribed to a service. Such restrictions help constrain resource overheads, and service related exposures. Accessing the service through an ISP's resolver complicates this issue, however ISPs will likely want to avoid the level of DNS traffic that indirect access might generate. Rather than attempting to subjectively describe domains as being "big" or "important", a list of the ongoing malicious activity instead offers the requester of the information a sound basis for their response to currently active threats, such as those defined in RFC5070. 1. admin, Administrative privileges were attempted. 2. dos. A denial of service was attempted. 3. file. An action that impacts the integrity of a file or database was attempted. 4. info-leak. An attempt was made to exfiltrate information. 5. misconfiguration. An attempt was made to exploit a mis- configuration in a system. 6. policy. Activity violating site's policy was attempted. 7. recon. Reconnaissance activity was attempted. 8. social-engineering. A social engineering attack was attempted. 9. user. User privileges were attempted. 10. unknown. The classification of this activity is unknown. 11. ext-value. An escape value used to extend this attribute. See Section 5.1. The requester, perhaps with help from other organizations or services, need to weigh currently reported threats against potential disruptions in commerce that the requester has with the specific domain. This would be something that the requester should know far better than those detecting threats or abusive activity. The requester of the information should already know in some manner with whom and to what level of commerce they or their customers have with a particular domain. After all, a decision to block is well beyond what threat investigators should make. The "secret sauce" should never be a secret to the requester of the information. The requester needs concise and reliable information for the decisions they need to make. Categories can be identified as an ENUM field (N) and incident counts (IC), which could be returned as an RR set of IPv4 addresses. Different RR sets can be placed within different sub-domains related to the specific service monitored, as John Levine had suggested. A linear incident count has a tendency of exposing detection methods. Instead, incident counts should be expressed as a natural log value. This exponent matches well with detections seen as domains become larger and have more diverse exchanges. As such, the incident count, (ICa or ICb), must never exceed 2.29 x 10^27 for the measured duration, or e^63. This also allows Na or Nb to represent one of 31 different threat categories. Additional threat categories can be specifically defined for the different services being measured, where the total categories being reported is limited to the number of addresses that can be returned within a DNS message. When 13 IPv4 addresses can be returned within an RR set, then 26 different categories can be reported. The value returned in each A record could be: 255 x 2^23 + Na x 2^17 + ICa x 2^11 + Nb x 2^6 + ICb The fields would be within bits 31-23, 22-17, 16-11, 10-6, 5-0 (127+128<<23) + (Na << 17) + (ICa << 11) + (Nb << 6) + ICb Without standardizing on the response returned by a service, there is little value in generically describing DNS as an amorphous solution later defined by various proprietary service providers. What would be the point of writing such a document anyway? > *Large query* Complete raw data about a domain can be retrieved via > HTTP in the form of an XML scheme. How this is handled really depends upon the nature and frequency of requests being made, and whether the information is being cached by the requester. In some cases, this information can be a set of hashes, or elaborate XML structures. This type of service using IODEF XML structures would help threat investigators to share their results and determine whether their own detection is being blocked. > *Taxonomy* Each domain's activity is described by a code (to be > determined). Possible uses of the code include estimating the > likelihood of phishing, transactional mail, ad campaigns for 3rd > parties, content by anonymous/unidentifiable users, liability for > abusive behavior. (More?) Yes. See above. > *Application specific quality* A domain reputation is affected by its > behavior. Email, web, chat, and other apps (which ones?) contribute > separate scores. Something like Threat Level Orange? This places too much of the decision process on to the service collecting threat information. In essence, a good/bad factor rating places defensive decisions onto the threat reporting service where they must also decide who is too big or too important to block. The requester, should know this for themselves, or ask this from a different type of service. This moves away from general and concise reporting of specific threats. The service should only need to share the overall activity monitored, and the duration that counts are held. > *Domains are ADMDs* When we talk of /domain/ reputation we mean the > ADMD, not the specific servers. (While DKIM exhibits a "d=" tag that > perfectly suits this purpose, I don't see the equivalent in other > apps or SPF.) It would seem the definition for domain depends upon the specific service being monitored for abuse. > *Private implementation* Domain reputation data is collected and > maintained by private organizations using their own "secret sauce". > Clients may choose one or more DRS, based on their preferences. Such as how really big or important the domain is in the view of the service? It seems the requester is better served by deciding this for themselves. At least they would have no one else to blame when they make the wrong choice. > *Web of trust* Domain reputation data are collected by a number of > participating servers. The participating domains are linked to one > another in a directed graph with weights, thereby defining a web of > trust. Maintenance of data is largely automatic, based on incident > reports, abuse reports, and the like. This type of approach can be easily gamed by Bot-nets. Large amounts of traffic can be exchanged amongst their 0wned systems to skew whatever metrics the agregator of the information uses. Unless only AUTHENTICATED information is used to establish reputation, any domain, large or small, can be negatively impacted when assumed sources are used as a basis for metrics. Perhaps companies like Dunn and Bradstreet are better able to offer dependable information than using a strange brew of someone's secret sauce. > *MARF interface* The trusted entity that provides reputation data for > a given domain is among the targets of forwarded abuse reports. DRS > are a well-defined implementation of MARF, in the sense that > implementation-specific fields like Reported-URI and Reported-Domain > bear a well defined meaning, homogeneous across all DRS servers. Worthless for establishing categories beyond that of spam. > *IODEF interface* Incident reports received by network providers' > CSIRTs should affect a domain's reputation too, in case they can be > unambiguously attributed to a domain. Yes. RFC5070 offers a good starting point. > *DNSBL interface* Should these contribute directly to domains' > reputation? As for (some) incident reports, this would require a > standard rule to get the domain responsible for a given IP. There should be a way of exchanging IODEF information between abuse reporting services. This is already being done on a limited basis. -Doug From vesely@tana.it Sat Aug 28 02:57:59 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 A80C83A6853 for ; Sat, 28 Aug 2010 02:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.041 X-Spam-Level: X-Spam-Status: No, score=-4.041 tagged_above=-999 required=5 tests=[AWL=0.678, BAYES_00=-2.599, 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 HV4PgSk6wVAh for ; Sat, 28 Aug 2010 02:57:58 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 7FA953A6852 for ; Sat, 28 Aug 2010 02:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282989506; bh=Uex8EaCQ4OkE0KkSQcGUA7dk/k3oGID09XAhcNh71qI=; l=326; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=YnhIRTTghLRGa8Lv0zQMo0Y4By+43bTmyhnj7oiatMghXUo2vdQK8Y8XvlRAtXU1Q n2DiwGZfgAh9BHretcoHtxuBJ/E1Cf5uyin59eFASeV3A5wN+DBQnY25BnqYcp0FTs MeT64gjDwB2CxBJSi2SNCh9X3ingYkMxHdkCDDgg= 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; Sat, 28 Aug 2010 11:58:26 +0200 id 00000000005DC033.000000004C78DDC2.00003B3A Message-ID: <4C78DDC2.3080300@tana.it> Date: Sat, 28 Aug 2010 11:58:26 +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> <091A8C81-D804-4448-AF37-E252825D6EBD@cybernothing.org> In-Reply-To: <091A8C81-D804-4448-AF37-E252825D6EBD@cybernothing.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] 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: Sat, 28 Aug 2010 09:57:59 -0000 On 27/Aug/10 23:03, J.D. Falk wrote: > Thanks for trying to codify these, BTW. I'm looking forward to other replies. Thank you for your support. However, in order to elicit more responses, it may be useful if you (or some other chair candidate) will re-propose the call for a poll, as soon as the list seems final. From vesely@tana.it Sat Aug 28 03:27:17 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 C414D3A6852 for ; Sat, 28 Aug 2010 03:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.8] 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 wv+sWHXCQZxE for ; Sat, 28 Aug 2010 03:27:16 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id A18EA3A684B for ; Sat, 28 Aug 2010 03:27:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1282991266; bh=cPzyy6YGJnWPIrXRViiajFyfNi/TsleURxfYnsae+08=; l=7780; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=lGBA39JY1XZsnKX5q0Y/wqGwI2wk5jJ37hTjtvhmz5l56ySy/Zh7dBQoomf4d9yWr acY4SyfGydwzBJmItcVoEBvmrXN0u641Wm7cksiqgZ/yRyoYhG7cr2O3sTqe5tDm/t Mi3/Ec40ntrkNy6OJYLIhJF/O7R47NwmeL97oFmU= 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; Sat, 28 Aug 2010 12:27:46 +0200 id 00000000005DC03D.000000004C78E4A2.0000420D Message-ID: <4C78E4A2.20105@tana.it> Date: Sat, 28 Aug 2010 12:27:46 +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: Douglas Otis References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> In-Reply-To: <4C786C32.6060304@mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] 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: Sat, 28 Aug 2010 10:27:17 -0000 Doug, I really think we should settle what the topics are _before_ discussing their details. Your contribution indicates that we should break the "small query" issue into what fields we want to appear in the response. Beside "Taxonomy", I should have added *Threat category and incident count* The small query response includes recently reported incident counts, broken down into a fixed number of threat categories. I also add this (see below) *Emergency stop* A reputation server shall signal to clients when a domain's server(s) seem to have been compromised. On 28/Aug/10 03:53, Douglas Otis wrote: > To handle domains lacking path components, initial queries still need > their depth constrained as a defense against DDoS attacks. In other > words, the query scheme should establish registrar's domains, and then > only allow initial queries one level below these. Registrar domains > can be safely cached over long periods, and can be uniquely identified > by having a specific category. Do you mean that a resolver should block a query for some.deep.sub.sub.domain.of.dubious.example._rep.scorekeeper.example unless it has already seen a query for dubious.example._rep.scorekeeper.example? > It would be good to standardize on a method for restricting results to > clients subscribed to a service. Such restrictions help constrain > resource overheads, and service related exposures. Accessing the > service through an ISP's resolver complicates this issue, however ISPs > will likely want to avoid the level of DNS traffic that indirect > access might generate. A decent mail or web server should have its own caching resolver. Possibly, client apps (mail readers, browsers) may eventually want to query a reputation service too. I'm not sure this deserves much attention now. > Rather than attempting to subjectively describe domains as being "big" > or "important", a list of the ongoing malicious activity instead > offers the requester of the information a sound basis for their > response to currently active threats, such as those defined in RFC5070. Big or important is a relevant information, of course. > The requester, perhaps with help from other organizations or services, > need to weigh currently reported threats against potential disruptions > in commerce that the requester has with the specific domain. This > would be something that the requester should know far better than > those detecting threats or abusive activity. The requester of the > information should already know in some manner with whom and to what > level of commerce they or their customers have with a particular > domain. After all, a decision to block is well beyond what threat > investigators should make. The "secret sauce" should never be a secret > to the requester of the information. The requester needs concise and > reliable information for the decisions they need to make. If I've understood correctly, the question is how does scorekeeper.example tell me, given that I usually buy X from web.example, that web.example's server has recently been compromised? Then, I should wait a while before giving them my CC number again. Is that what you mean? Semantically, that's not the job of a reputation server. Probably, reputation just tells me what's the likelihood that web.example can be compromised, and, in case it is, how well they can handle the incident. At any rate, I add the "Emergency stop" entry above. > A linear incident count has a tendency of exposing detection methods. > Instead, incident counts should be expressed as a natural log value. > [math omitted] Agreed. I'd also consider a time convolution, so that recent incidents weight much more than ancient ones. In order to allow automatic updates, values should be maintained as real numbers. These may be rounded or transformed so as to match the response format that will be determined. > Without standardizing on the response returned by a service, there is > little value in generically describing DNS as an amorphous solution > later defined by various proprietary service providers. What would be > the point of writing such a document anyway? That's a crucial point, IMHO. Of course, reputation companies who have determined a recipe for a useful "secret sauce" and want to sell their service, would just do so. Standardization will eventually happen later. What are we doing, then? The DAC experience has to be considered and digested before we proceed: They have set up a certification service --the "big" and "important" facet of reputation--, have standardized it, and have failed, since I, for one, have not configured a list of trusted VBR certifiers, and don't know who would certify my domain. What went wrong? Did they contact the FDIC or whatever? (See the discussion between the two Johns in http://www.circleid.com/posts/fight_phishing_with_branding/) IMHO, standardization becomes meaningful if it provides for mutual interaction among reputation trackers, so that clients can resolve queries, and results are consistent according to a client's trust. >> *Domains are ADMDs* When we talk of /domain/ reputation we mean the >> ADMD, not the specific servers. (While DKIM exhibits a "d=" tag that >> perfectly suits this purpose, I don't see the equivalent in other >> apps or SPF.) > > It would seem the definition for domain depends upon the specific > service being monitored for abuse. Would it make sense to derive the domain from certificates' email addresses? >> *Web of trust* Domain reputation data are collected by a number of >> participating servers. The participating domains are linked to one >> another in a directed graph with weights, thereby defining a web of >> trust. Maintenance of data is largely automatic, based on incident >> reports, abuse reports, and the like. > > This type of approach can be easily gamed by Bot-nets. Large amounts > of traffic can be exchanged amongst their 0wned systems to skew > whatever metrics the agregator of the information uses. Yes, but if their contribution is correctly weighted according to the trust-path, only requesters who trust them will see it. > Unless only AUTHENTICATED information is used to establish > reputation, any domain, large or small, can be negatively impacted > when assumed sources are used as a basis for metrics. This is where DKIM becomes a useful anti-spam tool. >> *MARF interface* The trusted entity that provides reputation data for >> a given domain is among the targets of forwarded abuse reports. DRS >> are a well-defined implementation of MARF, in the sense that >> implementation-specific fields like Reported-URI and Reported-Domain >> bear a well defined meaning, homogeneous across all DRS servers. > > Worthless for establishing categories beyond that of spam. Yup, the idea is to track how well domains handle outgoing mail abuse. >> *IODEF interface* Incident reports received by network providers' >> CSIRTs should affect a domain's reputation too, in case they can be >> unambiguously attributed to a domain. > > Yes. RFC5070 offers a good starting point. > >> *DNSBL interface* Should these contribute directly to domains' >> reputation? As for (some) incident reports, this would require a >> standard rule to get the domain responsible for a given IP. > > There should be a way of exchanging IODEF information between abuse > reporting services. This is already being done on a limited basis. Someone familiar with those practices should say how to derive domain reputation from such data. Is there anyone from INCH on this list? From R.E.Sonneveld@sonnection.nl Sat Aug 28 03:54:38 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 351193A6861 for ; Sat, 28 Aug 2010 03:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=-1.844, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 1WgPZ6nLPTqJ for ; Sat, 28 Aug 2010 03:54:37 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id D3B0C3A685A for ; Sat, 28 Aug 2010 03:54:36 -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 <0L7U00O3NZNU1V00@lion.sonnection.nl> for domainrep@ietf.org; Sat, 28 Aug 2010 12:55:07 +0200 (CEST) Message-id: <4C78EB0A.2040003@sonnection.nl> Date: Sat, 28 Aug 2010 12:55:06 +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 References: <4C779114.3050109@tana.it> <091A8C81-D804-4448-AF37-E252825D6EBD@cybernothing.org> <4C78DDC2.3080300@tana.it> In-reply-to: <4C78DDC2.3080300@tana.it> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1282992907; bh=2mTSEYAZ8Xyqla+vGULyKVNfNvJwj3s+Akp5UVGw4NI=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C56Y+7SirORIpA6OJ6tOt0WTQMrwG5vOUpQVc/LL5v+WVnbmeVATvCnr4x8MzEaUe 1o6B+3ELamCOTw38u3/xOyw9RslaGz+moyLGdLsfafBwZhKoQkqibgP2NDRx8R/oyn 1EL7YQ7cbnpKvBLyg8UbEzyxHtEA9aba2B1JPZC8= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7U00O3NZNU1V00 Cc: Alessandro Vesely Subject: Re: [domainrep] 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: Sat, 28 Aug 2010 10:54:38 -0000 Hi, Alessandro, On 08/28/2010 11:58 AM, Alessandro Vesely wrote: > On 27/Aug/10 23:03, J.D. Falk wrote: >> Thanks for trying to codify these, BTW. I'm looking forward to other >> replies. > > Thank you for your support. However, in order to elicit more > responses, it may be useful if you (or some other chair candidate) > will re-propose the call for a poll, as soon as the list seems final. working on the draft I have started analyzing all threads of the domainrep list. To prevent an endless stream of replies and forks of discussions, I suggest the following strategy: for each of the requirements in the list of Alessandro I start a thread with Subject which provides a summary of what has been proposed, the pro's and con's and possibly a list of questions left open. Then each requirement can be discussed and at the end of the day the chair can start a call for a poll. But first we need to finalize the list created by Alessandro (we can do this within this thread). As far as I can see most items has been covered; what I'm missing from the list is the 'Industry Taxonomy'. It has been discussed a number of times here and later on it was proposed to define a Threat Activity Taxonomy instead of an 'Industry Taxonomy'. For the moment I suggest to add the Industry Taxonomy; for each of the requirements we will discuss whether it really should be incorporated into the draft or whether it can be dropped. Another one that I'd like to add is 'Scalability'. It will apply to both 'small queries' as to 'large queries'. BTW: I propose to change the name 'small query' and 'large query' to 'small footprint reputation system' and 'large footprint reputation system', as a 'small query' can have a large amount of data being sent back to the requester. /rolf From R.E.Sonneveld@sonnection.nl Sat Aug 28 15:37: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 9926C3A687F for ; Sat, 28 Aug 2010 15:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[AWL=-3.060, 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 xh+QCJFheqDd for ; Sat, 28 Aug 2010 15:37:29 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id 8CE4D3A687B for ; Sat, 28 Aug 2010 15:37:28 -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 <0L7V00N1OW7A5L00@lion.sonnection.nl> for domainrep@ietf.org; Sun, 29 Aug 2010 00:37:59 +0200 (CEST) Message-id: <4C798FC6.8020400@sonnection.nl> Date: Sun, 29 Aug 2010 00:37:58 +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=------------010109070603090502030906 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1283035078; bh=pk0VMsJU8FDpVjNMafOr5ZLEnnOc2q1cU/5V+o9P93g=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=adE1COLq++8b6qa7UHXKKOgX+z7BXxk7ur1/jkwJI2KIybKstDLwaJqbP5W4PjABY HRWvE4nikSsO60vAwi168z8ytGXKmNjeUzZa5nTe11ey9H3yLgdK9EFBgBXFTnodQ+ wGEHYVyM8YKlFxs96L0vWuvQ2Y303GqKQLV7IvCY= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7V00N1OW7A5L00 Subject: [domainrep] Small footprint reputation system 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: Sat, 28 Aug 2010 22:37:30 -0000 This is a multi-part message in MIME format. --------------010109070603090502030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, all to make a start with the list of requirements, proposed by Alessandro, here is the first item: small footprint reputation system. Some of the items/aspects below are not specific to the small footprint reputation system but equally apply to other types of reputation systems. Quite a number of the items below are copy-paste'd from mail from group members. Please note: I have tried to gather the information which was sent to the list by the list members, I have tried very hard to stay away from judging the contributions and from biased reading. As I've not have enough time to read all messages, it is my feeling that I'm still missing some information, regarding extra reputation fields (apart from the three mentioned below). What has been proposed? Reputation provider provides an answer consisting of three numbers: 1. quality score 2. confidence 3. NAICS (like) number Characteristics: * small reputation answer (255 bytes and 512 bytes has been mentioned) * implementor-agnostic * domain reputation may not have impact on reputation of subdomain(s) or URIs and vice versa * not e-mail specific * location in DNS for domain: some.domain._rep.scorekeeper.example * location in DNS for specific protocol: some.domain._rep.scorekeeper.example * can be: * * uri scheme * * port numbers (port 0 for ANY) * * other * quality of domain score: 0-99 * confidence of opinion score: 0-99 * other proposal for score was: use one byte using two's complement arithmetic * cooperative distributed open database (question: is this part of the scope?) * A scalar reputation scoring is absolutely necessary * suggestion to use 'DNS Response Policy Zones (DNS RPZ)' to prevent attacks * multiple reputation providers pro's mentioned by list members: * DNS has advantage when querying per message con's mentioned by list members: * "That's not what the DNS is for!" resistance we get in the IETF * how does one avoid walking the DNS tree when making queries against domains that may not be real? * DNS is not good at exchanging details that are needed to sustain listings. Because everyone uses a different database, the strategy has been to use xml schemes as templates for exchanging information between different databases. * it is not apparent how will this can block an exploit on some user's web page without blocking the entire domain * Nearly all large providers emit a fair amount of malicious content due to the number of compromised accounts General remarks: * which identity has been adequately authenticated for the purpose of assigning administrative reputations * Solve the difficult problem first, the support of domain blocking decisions. Questions asked, some of them still unanswered: * Will all unknown domains be initially assigned a maximal negative rating? * no XML for the small footprint reputation system? * Does this approach assume scorekeeper.example uses wildcard expansion to capture random sub-domains used by bad actors at high rates? * What is the result when scorekeeper.example does not respond before a DNS timeout? * What is the result when scorekeeper.example returns no answer for a domain being queried? * Shouldn't scorekeeper.example return an epoch time for the period a domain belongs to the same owner? * How does scorekeeper.example defend their service from abusive clients? * what is returned if domain is not present at reputation provider (NXDOMAIN)? * should there be correlation between domain reputations for different protocols (for the same domain)? * when URI reputation is to be addressed, do we need to look at path elements in addition to domains * why should the interesting part of the query have to include a domain name that exists in the DNS? I suggest we now first concentrate on the list of questions, and try to find answers for those questions which has not yet been answered. I plan to send two message on Monday: one on 'Scope' and one on 'Industry Taxonomy'. Have a nice weekend, /rolf --------------010109070603090502030906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all

to make a start with the list of requirements, proposed by Alessandro, here is the first item: small footprint reputation system. Some of the items/aspects below are not specific to the small footprint reputation system but equally apply to other types of reputation systems. Quite a number of the items below are copy-paste'd from mail from group members. Please note: I have tried to gather the information which was sent to the list by the list members, I have tried very hard to stay away from judging the contributions and from biased reading. As I've not have enough time to read all messages, it is my feeling that I'm still missing some information, regarding extra reputation fields (apart from the three mentioned below).

What has been proposed? Reputation provider provides an answer consisting of three numbers:
  1. quality score
  2. confidence
  3. NAICS (like) number

Characteristics:
  • small reputation answer (255 bytes and 512 bytes has been mentioned)
  • implementor-agnostic
  • domain reputation may not have impact on reputation of subdomain(s) or URIs and vice versa
  • not e-mail specific
  • location in DNS for domain: some.domain._rep.scorekeeper.example
  • location in DNS for specific protocol: some.domain.<protocol>_rep.scorekeeper.example
  • <protocol> can be:
  •   * uri scheme
  •   * port numbers (port 0 for ANY)
  •   * other
  • quality of domain score: 0-99
  • confidence of opinion score: 0-99
  • other proposal for score was: use one byte using two's complement arithmetic
  • cooperative distributed open database (question: is this part of the scope?)
  • A scalar reputation scoring is absolutely necessary
  • suggestion to use 'DNS Response Policy Zones (DNS RPZ)' to prevent attacks
  • multiple reputation providers

pro's mentioned by list members:
  • DNS has advantage when querying per message

con's mentioned by list members:
  • "That's not what the DNS is for!" resistance we get in the IETF
  • how does one avoid walking the DNS tree when making queries against domains that may not be real?
  • DNS is not good at exchanging details that are needed to sustain listings.  Because everyone uses a different database, the strategy has been to use xml schemes as templates for exchanging information between different databases.
  • it is not apparent how will this can block an exploit on some user's web page without blocking the entire domain
  • Nearly all large providers emit a fair amount of malicious content due to the number of compromised accounts

General remarks:
  • which identity has been adequately authenticated for the purpose of assigning administrative reputations
  • Solve the difficult problem first, the support of domain blocking decisions.

Questions asked, some of them still unanswered:

  • Will all unknown domains be initially assigned a maximal negative rating?
  • no XML for the small footprint reputation system?
  • Does this approach assume scorekeeper.example uses wildcard expansion to capture random sub-domains used by bad actors at high rates?
  • What is the result when scorekeeper.example does not respond before a DNS timeout?
  • What is the result when scorekeeper.example returns no answer for a domain being queried?
  • Shouldn't scorekeeper.example return an epoch time for the period a domain belongs to the same owner?
  • How does scorekeeper.example defend their service from abusive clients?
  • what is returned if domain is not present at reputation provider (NXDOMAIN)?
  • should there be correlation between domain reputations for different protocols (for the same domain)?
  • when URI reputation is to be addressed, do we need to look at path elements in addition to domains
  • why should the interesting part of the query have to include a domain name that exists in the DNS?

I suggest we now first concentrate on the list of questions, and try to find answers for those questions which has not yet been answered.

I plan to send two message on Monday: one on 'Scope' and one on 'Industry Taxonomy'.
Have a nice weekend,

/rolf
--------------010109070603090502030906-- From dotis@mail-abuse.org Sat Aug 28 18:11: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 E31DF3A68F8 for ; Sat, 28 Aug 2010 18:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.653 X-Spam-Level: X-Spam-Status: No, score=-104.653 tagged_above=-999 required=5 tests=[AWL=-1.313, BAYES_20=-0.74, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, SARE_BAYES_5x8=0.8, 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 T-PU5UXSSiEs for ; Sat, 28 Aug 2010 18:11:12 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 586AE3A68F6 for ; Sat, 28 Aug 2010 18:11:12 -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 818E0A9454C; Sun, 29 Aug 2010 01:11:38 +0000 (UTC) Message-ID: <4C79B3CA.3040006@mail-abuse.org> Date: Sat, 28 Aug 2010 18:11:38 -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: Alessandro Vesely References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> In-Reply-To: <4C78E4A2.20105@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] 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: Sun, 29 Aug 2010 01:11:21 -0000 On 8/28/10 3:27 AM, Alessandro Vesely wrote: > Doug, > I really think we should settle what the topics are _before_ > discussing their details. Details still help with imagining a view at 10,000 feet. :^) > Your contribution indicates that we should break the "small query" > issue into what fields we want to appear in the response. Beside > "Taxonomy", I should have added > > *Threat category and incident count* > The small query response includes recently reported incident counts, > broken down into a fixed number of threat categories. > > I also add this (see below) > > *Emergency stop* > A reputation server shall signal to clients when a domain's server(s) > seem to have been compromised. Be careful. Don't suggest threat monitoring services should make critical decisions of when to block a legitimate domain's service. There is always a compromised system issuing messages through any ISP's outbound server. Since email is store and forward, which server has really been compromised? With web services, there might be an iFrame injected in one of their customer's web-page's. This leaves the basic question as to what represents an emergency? The requester of threat information always needs to weigh threat incidents against their own relationship with the particular domain, and not expect blocking decisions will always be made for them by a monitoring service. The requester should assess the relative importance of the sending domain, as balanced against their specific security needs. This is not a decision a monitoring service can make well, since any such decision would often be based upon wild speculation. When an email provider serving the Netherlands is emitting malware spam, a requester located in Japan will likely apply much lower blocking thresholds for this domain than a requester located in the Netherlands, based simply upon current levels of legitimate commerce. The appropriate threshold also needs to reflect the security needs of the requester, such as a petrochemical plant will differ significantly from that of a flower shop. In other words, a threat monitoring service should not be expected to know which domains are important to a requester. Such a model will not work well at an Internet scale. As such, threat service information should be combined with information gathered or obtained by the requester measuring their current level of commerce with the specific domain. The requester, and not a threat monitoring service, will better understand the relative importance and the level of disruption a blocking decision might create, and only the requester can weigh this disruption against their security needs. > On 28/Aug/10 03:53, Douglas Otis wrote: >> To handle domains lacking path components, initial queries still need >> their depth constrained as a defense against DDoS attacks. In other >> words, the query scheme should establish registrar's domains, and then >> only allow initial queries one level below these. Registrar domains >> can be safely cached over long periods, and can be uniquely identified >> by having a specific category. > > Do you mean that a resolver should block a query for > > some.deep.sub.sub.domain.of.dubious.example._rep.scorekeeper.example No. The defined query protocol used by the requester needs to allow a monitoring service a means to have cached results be applied against an entire branch of the name tree to squelch a common practice of using wild-cards with randomly generated sub-domains. The monitoring service also needs to be able to enforce these requirements, which might mean giving a "go-away" answer for a particular client. As such, only direct queries to the service should be used by clients, which can be made through their own local recursive resolvers. unknown.co.uk would be okay as an initial query that then signals that all sub-domains are also blocked. Initial queries at random.unknown.co.uk would mean a monitoring service will be inundated with queries for an infinite number of random domains that are essentially free for the bad actor. >> It would be good to standardize on a method for restricting results to >> clients subscribed to a service. Such restrictions help constrain >> resource overheads, and service related exposures. Accessing the >> service through an ISP's resolver complicates this issue, however ISPs >> will likely want to avoid the level of DNS traffic that indirect >> access might generate. > A decent mail or web server should have its own caching resolver. > Possibly, client apps (mail readers, browsers) may eventually want to > query a reputation service too. I'm not sure this deserves much > attention now. Before discussing what is needed to protect web browsing, please review http://code.google.com/apis/safebrowsing/developers_guide_v2.html Too many web pages have been compromised, where blocking at the domain would prove highly disruptive. >> Rather than attempting to subjectively describe domains as being "big" >> or "important", a list of the ongoing malicious activity instead >> offers the requester of the information a sound basis for their >> response to currently active threats, such as those defined in RFC5070. > > Big or important is a relevant information, of course. Agreed, but no threat monitoring service should be expected to know what is big or important from the perspective of the requester. Perhaps firewall products used by a requester might track their commerce with these domains, and bind this information with accounting and exchange rates. When requester specific information is then combined with current threat information, the firewall product can then make more appropriate blocking or warnings decisions tailored specifically for the requester. >> The requester, perhaps with help from other organizations or services, >> need to weigh currently reported threats against potential disruptions >> in commerce that the requester has with the specific domain. This >> would be something that the requester should know far better than >> those detecting threats or abusive activity. The requester of the >> information should already know in some manner with whom and to what >> level of commerce they or their customers have with a particular >> domain. After all, a decision to block is well beyond what threat >> investigators should make. The "secret sauce" should never be a secret >> to the requester of the information. The requester needs concise and >> reliable information for the decisions they need to make. > If I've understood correctly, the question is how does > scorekeeper.example tell me, given that I usually buy X from > web.example, that web.example's server has recently been compromised? > Then, I should wait a while before giving them my CC number again. Is > that what you mean? No. A monitoring service should not be making assumptions about the requester. Out of perhaps 26 categories of threats, perhaps one or two might relate to a service used to complete credit card transactions. When there are only a few recent incidents, and the card holder may be willing to closely monitor their card's activity, and decide not to block the domain. On the other hand, when the requester is a network for an airport control tower, and a domain showing some threat activity is not essential for their critical operations and the requester has noted no prior history, then they might correctly decide to block at any incident level, where they have set more appropriate thresholds for essential domains, such as faa.gov, norad.mil, aviationweather.gov, noaa.gov. etc. > Semantically, that's not the job of a reputation server. Probably, > reputation just tells me what's the likelihood that web.example can be > compromised, and, in case it is, how well they can handle the > incident. At any rate, I add the "Emergency stop" entry above. On what basis would this type of decision be made? >> A linear incident count has a tendency of exposing detection methods. >> Instead, incident counts should be expressed as a natural log value. >> [math omitted] > Agreed. I'd also consider a time convolution, so that recent > incidents weight much more than ancient ones. Stop expecting a centralized monitoring system is able to make critical domain blocking decisions for any requester. This is not a model that will work in today's threat landscape. Instead, allow the requester to interpret changes in incident information themselves. The requester needs to maintain their own domain information. Once a domain has been determined to be directly controlled by criminals, the reporting category should ensure any incident count offers sufficient warning against the entire domain. Perhaps threat monitoring services might also report failures in responding to threat reports, or incident count removals based upon the administrative trust extended by the monitoring service when told a category has been resolved. Each category can also represent different windows of time. > In order to allow automatic updates, values should be maintained as > real numbers. These may be rounded or transformed so as to match the > response format that will be determined. A sliding window based upon integer measurements made every 300 seconds works fairly well, with summations reported over a sliding window of say 3,600 and 86,400 seconds. Just as the human ear has exponential sensitivity allowing comprehension over a high dynamic range, so would exponential counts. To help a requester understand a change without them keeping a history, the reporting scheme could include two different measurement windows, where ICa might be 1 hour updated every 5 minutes, and ICb might be 1 day updated every hour, for example. >> Without standardizing on the response returned by a service, there is >> little value in generically describing DNS as an amorphous solution >> later defined by various proprietary service providers. What would be >> the point of writing such a document anyway? > That's a crucial point, IMHO. Of course, reputation companies who > have determined a recipe for a useful "secret sauce" and want to sell > their service, would just do so. Standardization will eventually > happen later. What are we doing, then? It seems some believe that the approach taken to report on IPv4 addresses can be directly applied to that of a domain, where the term "secret sauce" might be an unwillingness to admit security must then be secondary to a concern of generating too many support calls. > The DAC experience has to be considered and digested before we > proceed: They have set up a certification service --the "big" and > "important" facet of reputation--, have standardized it, and have > failed, since I, for one, have not configured a list of trusted VBR > certifiers, and don't know who would certify my domain. What went > wrong? Did they contact the FDIC or whatever? (See the discussion > between the two Johns in > http://www.circleid.com/posts/fight_phishing_with_branding/) > > IMHO, standardization becomes meaningful if it provides for mutual > interaction among reputation trackers, so that clients can resolve > queries, and results are consistent according to a client's trust. Our company supported the Domain Assurance Council, but John Klensin is right on this issue, while seeing the issues differently. One, paying an organization to say something about your domain will not deter bad actors. Someone will always take their money and a large number of domains will be willing to join them in a race to the bottom. Secondly, schemes attempting to "push" accountability onto "authorized" domains have and are destine to fail. The authorization scheme is easily gamed, since providers don't know what identity, if any, must correspond to an authorization. This situation might change. The exchange of email from IPv6 addresses will eventually require cryptographic validation of SMTP clients. An IP address seen by servers may not represent the IP address used by the client. Having a more meaningful WHOIS tied to an IODEF monitoring system seems to represent the best path forward, provided there is the political will to hold providers responsible for monitoring their networks, and to identify the entities associated with domains engaged in commerce. >>> *Domains are ADMDs* When we talk of /domain/ reputation we mean the >>> ADMD, not the specific servers. (While DKIM exhibits a "d=" tag that >>> perfectly suits this purpose, I don't see the equivalent in other >>> apps or SPF.) >> >> It would seem the definition for domain depends upon the specific >> service being monitored for abuse. > > Would it make sense to derive the domain from certificates' email > addresses? Hopefully, domain reputation does not find itself limited to just email use. There is an effort call keyassure that might be able to leverage DNSsec to allow use of public keys. There is too much money involved with Internet crime to expect the cost of a certificate will do much to impair criminal activity. Nor would I expect any service will be willing to single out individuals, or that such authenticated information will be generally available with respect to individual email addresses. >>> *Web of trust* Domain reputation data are collected by a number of >>> participating servers. The participating domains are linked to one >>> another in a directed graph with weights, thereby defining a web of >>> trust. Maintenance of data is largely automatic, based on incident >>> reports, abuse reports, and the like. >> >> This type of approach can be easily gamed by Bot-nets. Large amounts >> of traffic can be exchanged amongst their 0wned systems to skew >> whatever metrics the agregator of the information uses. > > Yes, but if their contribution is correctly weighted according to the > trust-path, only requesters who trust them will see it. Do you really think there is a way this can scale? Look at how successful bad actors are at corrupting search results. In this case, the trust path is normally within the same organization. When some service attempts to distill the "strange brew" into something indicating domain X is bad, should domain X have any recourse? When domain X prevails, will this then mean these services will need to relocate to countries where domains once again have no legal recourse? >> Unless only AUTHENTICATED information is used to establish >> reputation, any domain, large or small, can be negatively impacted >> when assumed sources are used as a basis for metrics. > This is where DKIM becomes a useful anti-spam tool. Disagree. No one has ever claimed that DKIM is useful at preventing spam. It is only useful at mitigating false positive detections of phishing attempts, and the white-listing of domains some consider "too big" to block. In the latter case, this will actually increase the level of spam. Putting in place a cryptographic mechanism to authenticate the SMTP client can make a difference in the level of spam by holding those who introduce the abuse accountable, and not pretending to hold those who may have done so accountable. Wanting to believe DKIM really indicates who introduced the message overlooks that DKIM does not indicate where the message was directed, and that any message can be replayed. >>> *MARF interface* The trusted entity that provides reputation data for >>> a given domain is among the targets of forwarded abuse reports. DRS >>> are a well-defined implementation of MARF, in the sense that >>> implementation-specific fields like Reported-URI and Reported-Domain >>> bear a well defined meaning, homogeneous across all DRS servers. >> >> Worthless for establishing categories beyond that of spam. > > Yup, the idea is to track how well domains handle outgoing mail abuse. > >>> *IODEF interface* Incident reports received by network providers' >>> CSIRTs should affect a domain's reputation too, in case they can be >>> unambiguously attributed to a domain. >> >> Yes. RFC5070 offers a good starting point. >> >>> *DNSBL interface* Should these contribute directly to domains' >>> reputation? As for (some) incident reports, this would require a >>> standard rule to get the domain responsible for a given IP. >> >> There should be a way of exchanging IODEF information between abuse >> reporting services. This is already being done on a limited basis. > > Someone familiar with those practices should say how to derive domain > reputation from such data. Is there anyone from INCH on this list? Paul Ferguson might be a good person to ask. -Doug From fergdawgster@gmail.com Sat Aug 28 18:25:37 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 BBD8C3A6894 for ; Sat, 28 Aug 2010 18:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_05=-1.11] 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 0QTGPl9daI2T for ; Sat, 28 Aug 2010 18:25:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 5BF873A6358 for ; Sat, 28 Aug 2010 18:25:36 -0700 (PDT) Received: by wyi11 with SMTP id 11so5629359wyi.31 for ; Sat, 28 Aug 2010 18:26:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=FBr2poolCbyWI0eA5YD2HKyQD8CCEs28O/Al8fpqzYc=; b=EI4DHCw6EplKIzdo12HgpHrLHdJNmnNllKvWUsGeuoVYUKjcnKFT3T0qgMHuyvUVHx r0uRrttXcP7aWaJupAD51Vtl+LFqNxYh0XWmy9wP2Bf8f8weeUeMaRoiRfdBpXAhdpML 2QTHveHV3av68ALZWA0rqnk4O/GhwdWTd2I0s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cCOis7Fl51KkbTPLbCXJBmREdxVHCvgRJFzYw+DMiFStF2ijYrMVOWibAIIycyJ7V6 l0TMgedxyqmTXdFobW59k23wM8/BYKNzq59jYM0jWgG0/byXws2XkSEJnV6R+r/736bY Xsb+MxvZIW6olD1BoUR2c94FhCrCel4PaNjgg= MIME-Version: 1.0 Received: by 10.216.232.144 with SMTP id n16mr3061181weq.1.1283045167410; Sat, 28 Aug 2010 18:26:07 -0700 (PDT) Received: by 10.216.72.130 with HTTP; Sat, 28 Aug 2010 18:26:07 -0700 (PDT) In-Reply-To: <4C79B3CA.3040006@mail-abuse.org> References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> Date: Sat, 28 Aug 2010 18:26:07 -0700 Message-ID: From: Paul Ferguson To: Douglas Otis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: domainrep@ietf.org, Alessandro Vesely Subject: Re: [domainrep] 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: Sun, 29 Aug 2010 01:25:37 -0000 On Sat, Aug 28, 2010 at 6:11 PM, Douglas Otis wrote: > =A0On 8/28/10 3:27 AM, Alessandro Vesely wrote: >>> >>> There should be a way of exchanging IODEF information between abuse >>> reporting services. This is already being done on a limited basis. >> >> Someone familiar with those practices should say how to derive domain >> reputation from such data. =A0Is there anyone from INCH on this list? > > Paul Ferguson might be a good person to ask. > Well, I don't claim to be "from INCH" -- since I didn't really participate in the IETF WG -- but I did a bit of operational research on this issue a couple of years ago when a similar topic was being discussed on how CERTs (Computer Emergency Response Teams, not Certificates) interact with one another in exchanging incident information. Part of what I do on a day-to-day basis is interact with lots of people at CERTs globally, and of course, I think that IODEF could be used in reporting security incidents and could certainly be adopted to in a larger context. The upshot of it is that IODEF, while defined, has not enjoyed widespread usage in the CERT community, although there are a few organizations which *do* use it -- the APWG and JP-CERT being two that immediately leap to mind. Pat Cain @ the APWG is the right guy to talk to on that (if anyone needs his contact information, please ping me) and he was very active in the INCH efforts w.r.t. IODEF. With regards to deriving domain reputation metrics from that data, I would think that would be a no-brainer, since the data is generated based on "incidents" and methinks that would provide crucial information regarding what reputation could be applied to a malicious source/host/domain/whatever. - ferg --=20 "Fergie", a.k.a. Paul Ferguson =A0Engineering Architecture for the Internet =A0fergdawgster(at)gmail.com =A0ferg's tech blog: http://fergdawg.blogspot.com/ From vesely@tana.it Sun Aug 29 04:42:52 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 EFA383A67FC for ; Sun, 29 Aug 2010 04:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.077 X-Spam-Level: X-Spam-Status: No, score=-4.077 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, 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 8q8h6ZX8Un8B for ; Sun, 29 Aug 2010 04:42:50 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 905093A6807 for ; Sun, 29 Aug 2010 04:42:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1283082196; bh=0KgSH4YLW0YPPPdlQmc4FHmeDNTREaNPi4ehAGNxkas=; l=1696; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=M7yMCEKZ5maDORRYW1UFA64iz44RUYt1hC4IM+3KYhcWXsahkfzU16ZCNkxf5JTqz 7BG5scNKWJ08TVPRUncEktWvj+dCQvVh9Uz9e2A5qnM8GxxqfodnmqvZj/tIqjDWNH 5AvkjYfJTnJtJlrrU8U8uSNWTIHTmrGulaEppH0A= 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; Sun, 29 Aug 2010 13:43:16 +0200 id 00000000005DC035.000000004C7A47D4.00000BEF Message-ID: <4C7A47D3.1020503@tana.it> Date: Sun, 29 Aug 2010 13:43:15 +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: Paul Ferguson References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: [domainrep] IODEF interface (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: Sun, 29 Aug 2010 11:42:52 -0000 On 29/Aug/10 03:26, Paul Ferguson wrote: > CERTs (Computer Emergency Response Teams, not Certificates) Perhaps the term "CSIRT" has been coined to avoid such ambiguity? > Part of what I do on a day-to-day basis is interact with lots of > people at CERTs globally, and of course, I think that IODEF could be > used in reporting security incidents and could certainly be adopted to > in a larger context. At this stage, it suffices to be able to estimate the extent of network providers involvement in the domain reputation effort. As an email example, abusix.org sustain forwarding abuse reports to network providers (using yet another format :-O). They don't take steps to ensure that recipients won't just drop such reports, though. For our purposes, providers should feed (part of) incident data into the reputation system. That should rise privacy concerns, especially in case they don't directly host the relevant "reputation server". Presumably, different providers will want to engage at different degrees. We should even provide for "criminal" network providers. But what is the "normal" level of involvement they may want to commit themselves to? > The upshot of it is that IODEF, while defined, has not enjoyed > widespread usage in the CERT community, although there are a few > organizations which *do* use it -- the APWG and JP-CERT being two that > immediately leap to mind. Of course, life will be easier when formats will be standard. Even if this WG-wannabe aims at standardization, I don't think the format if of foremost importance for the time being. In that respect, this thread's subject is somewhat of a misnomer. From vesely@tana.it Sun Aug 29 06:49: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 8FC123A682F for ; Sun, 29 Aug 2010 06:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_50=0.001, 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 uyweu7AlslHu for ; Sun, 29 Aug 2010 06:49:04 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 3A9113A6827 for ; Sun, 29 Aug 2010 06:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1283089770; bh=vJnF0xMV7HaXMR+s6p/TyEF5mmxCmMe1Yb5o242J6Uo=; l=3935; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=UXxm9VHWhAUtTDuhuvxUdIl1VPEIF8y/vTDOJ1EfX1C0ObMqy2rojj+oZBbkOK8Sz 90VRbALIKoUGREe+QocFlZ1j7manE7SN3nOdYyJjA5mpTS1uUbesoxZsthQnVZ6qHI 5DH6DA/et5i4rp05ziRFj9P0yLOQ/xlbVfyj64Og= 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; Sun, 29 Aug 2010 15:49:30 +0200 id 00000000005DC033.000000004C7A656A.000052FD Message-ID: <4C7A6569.7050008@tana.it> Date: Sun, 29 Aug 2010 15:49:29 +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: Douglas Otis References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> In-Reply-To: <4C79B3CA.3040006@mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: [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: Sun, 29 Aug 2010 13:49:20 -0000 On 29/Aug/10 03:11, Douglas Otis wrote: > Details still help with imagining a view at 10,000 feet. :^) Fine. > Stop expecting a centralized monitoring system is able to make > critical domain blocking decisions for any requester. This is not a > model that will work in today's threat landscape. Agreed. Incidents may generally indicate a domain's quality, though. >> The DAC experience has to be considered [...] >> (See the discussion between the two Johns in >> http://www.circleid.com/posts/fight_phishing_with_branding/) >> >> IMHO, standardization becomes meaningful if it provides for mutual >> interaction among reputation trackers, so that clients can resolve >> queries, and results are consistent according to a client's trust. > Our company supported the Domain Assurance Council, but John Klensin > is right on this issue, while seeing the issues differently. One point is that it is not worth to insert lots of difficult-to-determine configuration details for only bettering a tiny part of traffic. > One, paying an organization to say something about your domain will > not deter bad actors. Someone will always take their money and a > large number of domains will be willing to join them in a race to > the bottom. IMHO, the service should be provided for free. > Secondly, schemes attempting to "push" accountability onto > "authorized" domains have and are destine to fail. The authorization > scheme is easily gamed, since providers don't know what identity, if > any, must correspond to an authorization. For email, a DKIM-signed abusive message inside a DKIM-signed abuse report can be assimilated to an incident, unless the original sender contests. Yet, incidents should not directly affect a domain's reputation. It is the /domain response/ to the incident that matters. >> if [each actors'] contribution is correctly weighted according to >> the trust-path, only requesters who trust them will see it. > Do you really think there is a way this can scale? It should scale just like IP allocations and domain delegations do. > When some service attempts to distill the "strange brew" into > something indicating domain X is bad, should domain X have any > recourse? When domain X prevails, will this then mean these > services will need to relocate to countries where domains once > again have no legal recourse? Possibly not. I haven't worked out a model, but the idea is that trust can be chained. For a rough example, assume A trusts B and B trusts C, with weights: A --0.8--> B --0.8--> C Thus A trusts C with weight 0.64, in a multiplicative model. Now, say C does not handle an incident that A reported to B. Because of that, B may lower its trust toward C to 0.4. If C prevails and B doesn't adjust its score, A may lower its trust toward B, e.g. again to 0.4. Thus, the final scores are either A --0.8--> B --0.4--> C or A --0.4--> B --0.8--> C In both cases, the score A-->C drops to 0.32. (Other circumstances may cause scores to raise, there may be multiple paths, and further intricacies to account for.) The above is just an oversimplified example that I hope renders the idea. Node B may be bad because of any reason, including legal coercion. However, B's friends may continue to trust it, and it may still work for them; a "global walled garden" does not have to be uniformly connected. Initial trust should be granted to network providers, registries and similar entities. Each domain should provide its server. Recourses and contestations should seldom cause human interventions because false claims can easily be punished by lowering scores. The difficulty is to enumerate all possible operations, and then elaborate a model that will track them correctly, allowing human intervention as appropriate. A case of collective intelligence? From dotis@mail-abuse.org Sun Aug 29 11:45:40 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 6BDA83A686D for ; Sun, 29 Aug 2010 11:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.716 X-Spam-Level: X-Spam-Status: No, score=-104.716 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_50=0.001, GB_ABOUTYOU=0.5, 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 48oSKtyGJYgK for ; Sun, 29 Aug 2010 11:45:38 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 79C513A686A for ; Sun, 29 Aug 2010 11:45:38 -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 5A85DA94482; Sun, 29 Aug 2010 18:46:05 +0000 (UTC) Message-ID: <4C7AAAED.5010408@mail-abuse.org> Date: Sun, 29 Aug 2010 11:46:05 -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: Alessandro Vesely References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> <4C7A6569.7050008@tana.it> In-Reply-To: <4C7A6569.7050008@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org 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: Sun, 29 Aug 2010 18:45:40 -0000 On 8/29/10 6:49 AM, Alessandro Vesely wrote: > On 29/Aug/10 03:11, Douglas Otis wrote: > > Stop expecting a centralized monitoring system is able to make > > critical domain blocking decisions for any requester. This is not > > a model that will work in today's threat landscape. > > Agreed. Incidents may generally indicate a domain's quality, > though. A centralized monitoring system will not have a basis in which to judge quality, except at toxic extremes. An accurate metric for overall volume is needed to make reasonable quality assessments. For example, water quality is reported in parts per million or billion. Incidents expressed as quality by a monitoring service would be speculating about volume. Such speculated volumes can be significantly influenced by bad actors. A requester or network provider, on the other hand, is able to accurately monitor their own volume metrics. Incident monitoring offers better information when it is not polluted by speculated volumes and reported as bogus quality measurements. Leave the decision of quality to network providers, and decisions of when to act to the requester. Mixing known reported incidents with speculated volumes reduces the information quality. If anything, report volume speculations as a separate category, to that of incident reporting, perhaps as category 0. > One point is that it is not worth to insert lots of > difficult-to-determine configuration details for only bettering a > tiny part of traffic. Do you mean reporting the category of commerce? If so, then I would agree the costs would not outweigh the benefit. Bad actors could then easily have themselves appear as being in one of these "too important" or "too big" categories. > > One, paying an organization to say something about your domain > > will not deter bad actors. Someone will always take their money and > > a large number of domains will be willing to join them in a race > > to the bottom. > > IMHO, the service should be provided for free. Do you mean that resource fees should offer adequate enforcement of related agreements? But even that is not really free. On the other hand, a monitoring service as a stop-gap effort will deal with DDoS attack and lawsuits, whose defense requires adequate funding. Or said another way, you don't get what you don't pay for. > > Secondly, schemes attempting to "push" accountability onto > > "authorized" domains have and are destine to fail. The > > authorization scheme is easily gamed, since providers don't know > > what identity, if any, must correspond to an authorization. > > For email, a DKIM-signed abusive message inside a DKIM-signed abuse > report can be assimilated to an incident, unless the original sender > contests. Yet, incidents should not directly affect a domain's > reputation. It is the /domain response/ to the incident that > matters. Disagree. There is nothing preventing bad actors from inundating the Internet with any domain's DKIM messages. A bad actor could obtain a Yahoo account, send themselves their spammy messages, and then replay them throughout the Internet. Should a domain abused by a monitoring service who wrongly holds a DKIM domain responsible for the actions of an unknown SMTP client really be expected to contest each injustice? What happens when the DKIM domain responds with a request to stop sending the abusive reports! Would this then allow the monitoring service to report the DKIM domain as unresponsive and a bad domain? > >> if [each actors'] contribution is correctly weighted according > >> to the trust-path, only requesters who trust them will see it. > > Do you really think there is a way this can scale? > > It should scale just like IP allocations and domain delegations do. Bad actors can indicate they trust their hundreds of thousands of 0wned systems. They can say bad things about your domain and replicate what has been said about the others, including their own which they will have managed to skew. They then send you a friendly message indicating they can improve your domains rating, at a moderate fee. Scaling trust on a free basis is something bot-nets are good at gaming. Time to put away the tie-dyed shirt, the era of free-trust is over. :^) > > When some service attempts to distill the "strange brew" into > > something indicating domain X is bad, should domain X have any > > recourse? When domain X prevails, will this then mean these > > services will need to relocate to countries where domains once > > again have no legal recourse? > > Possibly not. I haven't worked out a model, but the idea is that > trust can be chained. For a rough example, assume A trusts B and B > trusts C, with weights: > > A --0.8--> B --0.8--> C > > Thus A trusts C with weight 0.64, in a multiplicative model. Now, > say C does not handle an incident that A reported to B. Because of > that, B may lower its trust toward C to 0.4. If C prevails and B > doesn't adjust its score, A may lower its trust toward B, e.g. again > to 0.4. Thus, the final scores are either > > A --0.8--> B --0.4--> C or A --0.4--> B --0.8--> C > > In both cases, the score A-->C drops to 0.32. (Other circumstances > may cause scores to raise, there may be multiple paths, and further > intricacies to account for.) > > The above is just an oversimplified example that I hope renders the > idea. Node B may be bad because of any reason, including legal > coercion. However, B's friends may continue to trust it, and it may > still work for them; a "global walled garden" does not have to be > uniformly connected. > > Initial trust should be granted to network providers, registries and > similar entities. Each domain should provide its server. Recourses > and contestations should seldom cause human interventions because > false claims can easily be punished by lowering scores. The > difficulty is to enumerate all possible operations, and then > elaborate a model that will track them correctly, allowing human > intervention as appropriate. A case of collective intelligence? Let me quote the late great Frank Zappa, "Dumb all over and a little ugly on the side." When the basis for judging reputation is fundamentally flawed, does it really matter how many are willing to make the same mistake? -Doug http://www.youtube.com/watch?v=YGZ5isu23ow From vesely@tana.it Mon Aug 30 04:20:47 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 B6DCE3A67A3 for ; Mon, 30 Aug 2010 04:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_50=0.001, GB_ABOUTYOU=0.5, 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 Xb4lP-npODeV for ; Mon, 30 Aug 2010 04:20:46 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 02F323A6403 for ; Mon, 30 Aug 2010 04:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tana.it; s=test; t=1283167273; bh=wO8qzg/3AQVOxD6P1GaqUAZp5P5fbazL6ztrAdouHv0=; l=4119; h=Message-ID:Date:From:MIME-Version:To:CC:References:In-Reply-To: Content-Transfer-Encoding; b=GPV6J9mOKZ47mhqrP+biimNvjDzo6Z/ab3fuiIJvDI3s0u+nRLribsV4HxbI9XQSj RIopdPUWuWpXUxC18U6fpAL8xmIjh4TS1HCxm3KmVfhen7AeTb2gtQLRPTe843wvUA ldpXiNNCOnF/5mh+KDYT733wYmknQL7hE2rk6bMs= 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; Mon, 30 Aug 2010 13:21:13 +0200 id 00000000005DC037.000000004C7B9429.000019F9 Message-ID: <4C7B9429.3030600@tana.it> Date: Mon, 30 Aug 2010 13:21:13 +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: Douglas Otis References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> <4C7A6569.7050008@tana.it> <4C7AAAED.5010408@mail-abuse.org> In-Reply-To: <4C7AAAED.5010408@mail-abuse.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org 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: Mon, 30 Aug 2010 11:20:48 -0000 On 29/Aug/10 20:46, Douglas Otis wrote: > On 8/29/10 6:49 AM, Alessandro Vesely wrote: >> One point is that it is not worth to insert lots of >> difficult-to-determine configuration details for only bettering a >> tiny part of traffic. > > Do you mean reporting the category of commerce? If so, then I would > agree the costs would not outweigh the benefit. Including a huge list of trusted vouchers is hard, unless we introduce meta-vouchers (looks like pre-loaded X509 certifiers.) > Bad actors could then easily have themselves appear as being in one > of these "too important" or "too big" categories. Not in the FDIC, say. If all vouchers are carefully selected, none of them would vouch for unionbanknigeria.net. >> IMHO, the service should be provided for free. > > Do you mean that resource fees should offer adequate enforcement of > related agreements? But even that is not really free. On the other > hand, a monitoring service as a stop-gap effort will deal with DDoS > attack and lawsuits, whose defense requires adequate funding. Or said > another way, you don't get what you don't pay for. If it is my network provider, a national institution, or similar, resources are already paid for. An private independent service will have difficulties in gaining credibility; however, if it manages to do that business, they may charge some amount for /querying/, not for vouching. (Spamhaus won't take money to unlist addresses.) >> For email, a DKIM-signed abusive message inside a DKIM-signed abuse >> report can be assimilated to an incident, unless the original sender >> contests. Yet, incidents should not directly affect a domain's >> reputation. It is the /domain response/ to the incident that >> matters. > > Disagree. There is nothing preventing bad actors from inundating the > Internet with any domain's DKIM messages. A bad actor could obtain a > Yahoo account, send themselves their spammy messages, and then replay > them throughout the Internet. Should a domain abused by a monitoring > service who wrongly holds a DKIM domain responsible for the actions of > an unknown SMTP client really be expected to contest each injustice? Yahoo should fire that account, as a response. Their policy for getting new accounts being what it is, they may have to do it several times. For the mechanics of replaying, you're right: DKIM signatures /alone/ do not attest the legitimacy of a message. > What happens when the DKIM domain responds with a request to stop > sending the abusive reports! Would this then allow the monitoring > service to report the DKIM domain as unresponsive and a bad domain? Reports should never be abusive, since they should only be shared by trusting parties. However, they can be sent by error, or in response to an attack. > Bad actors can indicate they trust their hundreds of thousands of > 0wned systems. They can say bad things about your domain and replicate > what has been said about the others, including their own which they > will have managed to skew. They then send you a friendly message > indicating they can improve your domains rating, at a moderate fee. Yeah, they also send 419 opportunities :-) > Scaling trust on a free basis is something bot-nets are good at > gaming. Time to put away the tie-dyed shirt, the era of free-trust is > over. :^) Despite banks often abusing that term, "trust" cannot really be bought, nor sold. >> [snipped vision of collective intelligence] > > Let me quote the late great Frank Zappa, "Dumb all over and a little > ugly on the side." When the basis for judging reputation is > fundamentally flawed, does it really matter how many are willing to > make the same mistake? Yes, it does! Frank's lyrics just implied it :-) Besides, I wouldn't despair of getting reputation judgments right. Even if we decide that we won't implement a web of trust, we should strive to avoid standardizing models that preclude it, if at all possible. > http://www.youtube.com/watch?v=YGZ5isu23ow Mighty grand, thanks! From nsb@guppylake.com Mon Aug 30 04:57: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 238013A69A9 for ; Mon, 30 Aug 2010 04:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.242 X-Spam-Level: * X-Spam-Status: No, score=1.242 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24] 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 46BsMpVN2dtt for ; Mon, 30 Aug 2010 04:57:38 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id A2C853A69A5 for ; Mon, 30 Aug 2010 04:57:22 -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 1Oq3Cx-0008Jv-7U for domainrep@ietf.org; Mon, 30 Aug 2010 08:11:28 -0400 From: Nathaniel Borenstein Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary=Apple-Mail-9--80409578 Date: Mon, 30 Aug 2010 07:57:48 -0400 In-Reply-To: <4C779114.3050109@tana.it> To: domainrep@ietf.org References: <4C779114.3050109@tana.it> Message-Id: <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> 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] 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: Mon, 30 Aug 2010 11:57:39 -0000 --Apple-Mail-9--80409578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Alessandro's "small and larger queries" -- which I like -- seem to point = towards a deeper aspect of the problem, and towards a few simple things = we can do to make the resulting protocol much more generally useful. = What I'm about to suggest doesn't affect most of what we've discussed on = this list, only the structure of the reputation information being passed = around. Most of us are on this mailing list because we want to use reputations = to attack email-related problems. We're inevitably going to worry = primarily about the aspects of reputation that apply to email. We = probably all agree on the need to itemize threat types; we haven't (yet) = all agreed on several other likely things such as organization types, = but they're obviously valid topics to discuss. Still, most of us want = to exclude from our scope the management of reputations for activities = such as kiddie porn, music piracy, aiding terrorists, swindling = consumers, etc. etc. But it's hard to deny that strong needs for = reputation exchange will emerge in all sorts of domains beyond email. = We should at least consider trying to get the basic idea right in the = first place, to make the system potentially reusable for such purposes. 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? The simplest "reputon" I can think of -- though I fear I'll shortly = learn just how oversimplistic it is -- looks like this strawman idea: AGENT-A (identified with confidence level X) says that AGENT-B has = PERCENTAGE likelihood (with confidence level Y) of ASSERTION. (Some = assertions will probably require encapsulating some arbitrary data as = part of the reputon.) More sophisticated information can be computed by matching multiple = reputons and facts together. The weight we give the above reputon might = depend on another reputon, assessing AGENT-A's value as a source of = reputation information. (Or we might base that assessment on our own = past observations.) =20 With the right definition of a reputon, we can easily devise syntax for = using it in the small and large queries. Each application using the = mechanism will define its own values of ASSERTION. (I'm guessing we = need a two-level namespace here.) I think we have the chance to produce = a pretty useful piece of infrastructure here, at very little (if any) = additional cost to us. It also suggests a divide-and-conquer approach = here -- one document could define a MIME type for reputons, another the = overall architecture for reputation management, two more could define = the small and large query types, and another the specific ASSERTIONs for = email reputations. Thoughts? -- Nathaniel --Apple-Mail-9--80409578 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Most of us are on this mailing list = because we want to use reputations to attack email-related = problems.  We're inevitably going to worry primarily about the = aspects of reputation that apply to email.  We probably all agree = on the need to itemize threat types; we haven't (yet) all agreed on = several other likely things such as organization types, but they're = obviously valid topics to discuss.  Still, most of us want to = exclude from our scope the management of reputations for activities such = as kiddie porn, music piracy, aiding  terrorists, swindling = consumers, etc. etc.  But it's hard to deny that strong needs for = reputation exchange will emerge in all sorts of domains beyond email. =  We should at least consider trying to get the basic idea right in = the first place, to make the system potentially reusable for such = purposes.

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?

The simplest "reputon" I can = think of -- though I fear I'll shortly learn just how oversimplistic it = is -- looks like this strawman = idea:

AGENT-A (identified with confidence level = X) says that AGENT-B has PERCENTAGE likelihood (with confidence = level Y) of ASSERTION.  (Some assertions will probably require = encapsulating some arbitrary data as part of the = reputon.)

More sophisticated information can be = computed by matching multiple reputons and facts together. =  The weight we give the above reputon might depend = on  another reputon, assessing AGENT-A's value as a source of = reputation information.  (Or we might base that assessment on our = own past observations.)  

With the right = definition of a reputon, we can easily devise syntax for using it in the = small and large queries.  Each application using the mechanism will = define its own values of ASSERTION.  (I'm guessing we need a = two-level namespace here.)  I think we have the chance to produce a = pretty useful piece of infrastructure here, at very little (if any) = additional cost to us.  It also suggests a divide-and-conquer = approach here -- one document could define a MIME type for reputons, = another the overall architecture for reputation management, two more = could define the small and large query types, and another the specific = ASSERTIONs for email = reputations.

Thoughts?  -- = Nathaniel

= --Apple-Mail-9--80409578-- From R.E.Sonneveld@sonnection.nl Mon Aug 30 15:02: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 3680F3A69EF for ; Mon, 30 Aug 2010 15:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.204 X-Spam-Level: X-Spam-Status: No, score=-3.204 tagged_above=-999 required=5 tests=[AWL=-1.701, BAYES_00=-2.599, 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 x3sCwbco+sTZ for ; Mon, 30 Aug 2010 15:02:01 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id F198C3A68C4 for ; Mon, 30 Aug 2010 15:01:59 -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 <0L7Z0021JJW2JB00@lion.sonnection.nl> for domainrep@ietf.org; Tue, 31 Aug 2010 00:02:27 +0200 (CEST) Message-id: <4C7C2A72.5070701@sonnection.nl> Date: Tue, 31 Aug 2010 00:02:26 +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=------------040803030704010300000505 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1283205747; bh=topiaRlfcDhs9O+JwtrXi2858u14jLE3cfygvSJ8QkA=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=UsX1EMHP8jiTBzeVcGm+Xp1b+gNOiIjt9AhZiNwY2ANJ1cQLwKll0d32rYzYguv/S 7I6l/EVzsBQFZgj7dLOgVcw9nIFTl6gig+rfmjW14L+y7HV0ITOV3rj86od+gMlQdI rtqHAGlMQ0BTsb7bnndtsZoGoPelTnB7tvxRlh6E= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7Z0021JJW2JB00 Subject: [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: Mon, 30 Aug 2010 22:02:02 -0000 This is a multi-part message in MIME format. --------------040803030704010300000505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, all as promised, in addition to the list of (tentative) requirements, sent to this list by Alessandro, I have tried to gather information from the discussions about 'scope'. We have seen a number of discussions, which sometimes were more or less in scope, some of them in part or in whole out of scope. But we can only say 'in scope' or 'out scope' if we first define what that scope exactly is. What are we trying to describe? Again, I have here and there copy-and-past'ed words or sentences from contributions to the list. What should be in scope (according to some): * just protocol, i.e. specification of how to ask a question and get an answer, versus which questions should be asked * just syntax * Asking about a domain name's reputation * not only e-mail What should be out of scope (according to some): * semantics * how to pick which domain name to ask about * what data is used to construct the answer * secret sauce of Domain Reputation Provider * whether the Domain Reputation Requester must first authenticate the domain before querying the Domain Reputation Provider Question: * is the way Domain Reputation Providers exchange their reputation information (between Domain Reputation Providers) in scope? Some say 'yes', but isn't that adding a complexity factor? * is the following question in scope, or out scope: if the unit of reputation c.q. the granularity of reputation is a single domainname, how can reputations be differentiated between different web pages within the same domain (e.g. big ISP or ESP or content provider); a similar question can be asked about differentiating between reputations of mail addresses within a domain. Is this discussion in scope? /rolf --------------040803030704010300000505 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all

as promised, in addition to the list of (tentative) requirements, sent to this list by Alessandro, I have tried to gather information from the discussions about 'scope'. We have seen a number of discussions, which sometimes were more or less in scope, some of them in part or in whole out of scope. But we can only say 'in scope' or 'out scope' if we first define what that scope exactly is. What are we trying to describe? Again, I have here and there copy-and-past'ed words or sentences from contributions to the list.

What should be in scope (according to some):

  • just protocol, i.e. specification of how to ask a question and get an answer, versus which questions should be asked
  • just syntax
  • Asking about a domain name's reputation
  • not only e-mail

What should be out of scope (according to some):

  • semantics
  • how to pick which domain name to ask about
  • what data is used to construct the answer
  • secret sauce of Domain Reputation Provider
  • whether the Domain Reputation Requester must first authenticate the domain before querying the Domain Reputation Provider

Question:
  • is the way Domain Reputation Providers exchange their reputation information (between Domain Reputation Providers) in scope? Some say 'yes', but isn't that adding a complexity factor?
  • is the following question in scope, or out scope:
    if the unit of reputation c.q. the granularity of reputation is a single domainname, how can reputations be differentiated between different web pages within the same domain (e.g. big ISP or ESP or content provider); a similar question can be asked about differentiating between reputations of mail addresses within a domain. Is this discussion in scope?

/rolf
--------------040803030704010300000505-- From R.E.Sonneveld@sonnection.nl Mon Aug 30 15:25: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 C4EE73A6882 for ; Mon, 30 Aug 2010 15:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-2.565, BAYES_20=-0.74, 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 pBZShKDqvy4y for ; Mon, 30 Aug 2010 15:24:47 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id EEFBE3A68D2 for ; Mon, 30 Aug 2010 15:24:41 -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 <0L7Z0021PKY0JB00@lion.sonnection.nl> for domainrep@ietf.org; Tue, 31 Aug 2010 00:25:12 +0200 (CEST) Message-id: <4C7C2FC8.4020806@sonnection.nl> Date: Tue, 31 Aug 2010 00:25:12 +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=------------090804000507060908090306 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1283207112; bh=N+CnJmajHRki0Fig9IzKF5QMnMzqf0x0CwB32msEcmY=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=hbObP9Ktzk527fuCj0Zb7Np4j7G1TwjzWtE7N0nEERrFo6cAZxacFYPmfQFwo6/GK NtlEmday/MhHmHqie/J5KlpnVmRW7e0h73JIjASmxOzRL9ct5zDjCpGIpBnb3d7eq6 TsKpniGRfdEA15OuqqXGXV+QqigQAO/geyrilxq4= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7Z0021PKY0JB00 Subject: [domainrep] Industry 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: Mon, 30 Aug 2010 22:25:18 -0000 This is a multi-part message in MIME format. --------------090804000507060908090306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, there has been proposed (in general) two sorts of taxonomy: an Industry Taxonomy and a Threat Taxonomy. This message tries to summarize what's been said about Industry Taxonomy. Industry taxonomy: * represents category of business * various registries proposed: - use NAICS (North America) - use ISIC (UN) - use Eurostat - use IANA registry * suggestion for categories 'unknown' and 'known malicious' * a code zero would mean don't know * for scalar reputation scoring, the value I would consider "Good" or "Bad" is different depending on the type of entity. "Good" for a free webmail provider might well be "Bad" for a bank. * not a mandatory part of the reputation answer; it's optional * include a mechanism to identify which registry is used (naics, isic etc. ) * "I think it should be as small as possible (but no smaller)" * Add WHOIS information (or define otherwise)? Pro's * pro of IANA: not NA centric * pro of NAICS: complete set, can be used Con's: * if organisation type is sent back, then why not any other element of the secret sauce? Seems like a slippery slope. * NAICS is NA-centric * ISIC is not as rich as NAICS * NAICS and ISIC (and probably Eurostat) can't describe every subcategory on earth * the nature of traffic from a domain could fit into several categories * do we really need it? Questions: * What NAICS like number will scorekeeper.example use for domains lacking ownership details? * What prohibits bad actors from masquerading as legitimate entities? As usual, some of these sentences were just copy-and-paste'd. And I've tried to stay away from judgments and biased reading. /rolf --------------090804000507060908090306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

there has been proposed (in general) two sorts of taxonomy: an Industry Taxonomy and a Threat Taxonomy. This message tries to summarize what's been said about Industry Taxonomy.

Industry taxonomy:

  • represents category of business
  • various registries proposed:
    - use NAICS (North America)
    - use ISIC (UN)
    - use Eurostat
    - use IANA registry
  • suggestion for categories 'unknown' and 'known malicious'
  • a code zero would mean don't know
  • for scalar reputation scoring, the value I would consider "Good" or "Bad" is different depending on the type of entity.  "Good" for a free webmail provider might well be "Bad" for a bank.
  • not a mandatory part of the reputation answer; it's optional
  • include a mechanism to identify which registry is used (naics, isic etc. )
  • "I think it should be as small as possible (but no smaller)"
  • Add WHOIS information (or define otherwise)?

Pro's
  • pro of IANA: not NA centric
  • pro of NAICS: complete set, can be used


Con's:
  • if organisation type is sent back, then why not any other element of the secret sauce? Seems like a slippery slope.
  • NAICS is NA-centric
  • ISIC is not as rich as NAICS
  • NAICS and ISIC (and probably Eurostat) can't describe every subcategory on earth
  • the nature of traffic from a domain could fit into several categories
  • do we really need it?

Questions:

  • What NAICS like number will scorekeeper.example use for domains lacking ownership details?
  • What prohibits bad actors from masquerading as legitimate entities?

As usual, some of these sentences were just copy-and-paste'd. And I've tried to stay away from judgments and biased reading.

/rolf
--------------090804000507060908090306-- From dotis@mail-abuse.org Mon Aug 30 15:29:01 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 E408D3A69EF for ; Mon, 30 Aug 2010 15:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.705 X-Spam-Level: X-Spam-Status: No, score=-104.705 tagged_above=-999 required=5 tests=[AWL=-1.206, BAYES_50=0.001, GB_ABOUTYOU=0.5, 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 W74UBk9asblV for ; Mon, 30 Aug 2010 15:29: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 A799D3A68B5 for ; Mon, 30 Aug 2010 15:29:00 -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 EEE9DA947CC; Mon, 30 Aug 2010 22:29:25 +0000 (UTC) Message-ID: <4C7C30C5.3040104@mail-abuse.org> Date: Mon, 30 Aug 2010 15:29: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: Alessandro Vesely References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> <4C7A6569.7050008@tana.it> <4C7AAAED.5010408@mail-abuse.org> <4C7B9429.3030600@tana.it> In-Reply-To: <4C7B9429.3030600@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org 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: Mon, 30 Aug 2010 22:29:02 -0000 On 8/30/10 4:21 AM, Alessandro Vesely wrote: > On 29/Aug/10 20:46, Douglas Otis wrote: > > Including a huge list of trusted vouchers is hard, unless we > introduce meta-vouchers (looks like pre-loaded X509 certifiers.) There may be a confirmation process developed to support a keyassure public key mechanisms that allows government de-certification, and confirmation of a domains' physical locations. > Bad actors could then easily have themselves appear as being in one > > of these "too important" or "too big" categories. > > Not in the FDIC, say. If all vouchers are carefully selected, none > of them would vouch for unionbanknigeria.net. Are you suggesting EV certificates would not be good enough for exchanging email? Will governments then need to confirm the new certificate type, and who will pay for the confirmation? > >> IMHO, the service should be provided for free. > > > > Do you mean that resource fees should offer adequate enforcement > > of related agreements? But even that is not really free. On the > > other hand, a monitoring service as a stop-gap effort will deal > > with DDoS attack and lawsuits, whose defense requires adequate > > funding. Or said another way, you don't get what you don't pay > > for. > > If it is my network provider, a national institution, or similar, > resources are already paid for. An private independent service will > have difficulties in gaining credibility; however, if it manages to > do that business, they may charge some amount for /querying/, not for > vouching. (Spamhaus won't take money to unlist addresses.) Okay, we agree service subscriptions might be used. This then requires a means to enforce query behavior and subscription payments, or more generally, a mechanism is needed to exclude non-subscribers or bad-actors. > >> For email, a DKIM-signed abusive message inside a DKIM-signed > >> abuse report can be assimilated to an incident, unless the > >> original sender contests. Yet, incidents should not directly > >> affect a domain's reputation. It is the /domain response/ to the > >> incident that matters. > > > > Disagree. There is nothing preventing bad actors from inundating > > the Internet with any domain's DKIM messages. A bad actor could > > obtain a Yahoo account, send themselves their spammy messages, and > > then replay them throughout the Internet. Should a domain abused by > > a monitoring service who wrongly holds a DKIM domain responsible > > for the actions of an unknown SMTP client really be expected to > > contest each injustice? > > Yahoo should fire that account, as a response. Their policy for > getting new accounts being what it is, they may have to do it several > times. So what if they do? Even accounts promptly disabled will not halt distributions of replayed messages, nor will rate limiting user accounts offer protection from replay abuse. A feature of DKIM is that a message can be redirected anywhere. DKIM domains can not be expected to contest each injustice of being wrongly accused of having assigned a message destination. > For the mechanics of replaying, you're right: DKIM signatures /alone/ > do not attest the legitimacy of a message. A DKIM domain does not identify who assigned the destination for an unsolicited message, especially when adopting a principle that assessment MUST allow domains a means to defend their reputation. A bad-actor will not need to be a user of the domain to replay messages. The SMTP client domain, and not the DKIM domain, MUST be used to establish reputations based upon receipt of unsolicited messages. > > What happens when the DKIM domain responds with a request to stop > > sending the abusive reports! Would this then allow the monitoring > > service to report the DKIM domain as unresponsive and a bad > > domain? > > Reports should never be abusive, since they should only be shared by > trusting parties. However, they can be sent by error, or in response > to an attack. Reports should always be directed to a domain verified as having issued the message to the recipient. DKIM does not offer such verification. It is not right to say since most messages are not replayed, it is safe to assume a message was not replayed when assessing reputations or when deciding where to send notifications. You know what they say about making assumptions... > > Bad actors can indicate they trust their hundreds of thousands of > > 0wned systems. They can say bad things about your domain and > > replicate what has been said about the others, including their own > > which they will have managed to skew. They then send you a friendly > > message indicating they can improve your domains rating, at a > > moderate fee. > > Yeah, they also send 419 opportunities :-) It is also difficult to detect and remove all outbound messages offering drugs, software, nude pictures of hot celebrities, undelivered packages, politicians caught in the act, claiming someone sent a large amount of spam, or that someone failed to pay for a service. Any such message might be replayed and used to entice victims into visiting malicious drive-by websites. At the same time, one of their ten of thousands of 0wned systems can also apply for new accounts, while granting access to pornography for those solving forwarded captchas. > > Scaling trust on a free basis is something bot-nets are good at > > gaming. Time to put away the tie-dyed shirt, the era of free-trust > > is over. :^) > > Despite banks often abusing that term, "trust" cannot really be > bought, nor sold. Certificates, vouching, and CA services are being bought and sold because people feel they can trust this information. The results of a searching service are intended to indicate where people are referencing a specific topic. Unfortunately, bot-nets continuously demonstrate a skill at corrupting search results obtained from the community. A large number of anything is progressively becoming less meaningful. > Even if we decide that we won't implement a web of trust, we should > strive to avoid standardizing models that preclude it, if at all > possible. No matter how reputation information is distributed, evidence supporting reputations MUST NOT be based upon any assumption of involvement. Holding an entity accountable for an unsolicited message means no assumptions regarding who assigned the destination can be allowed. Otherwise, bad-actors can quickly make such a system untrustworthy, disruptive, and wholly unfair. -Doug From R.E.Sonneveld@sonnection.nl Mon Aug 30 15:36:38 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 504C83A6A1A for ; Mon, 30 Aug 2010 15:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-2.255, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] 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 gNX3v5RYwvMg for ; Mon, 30 Aug 2010 15:36:33 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id 97D633A6A1F for ; Mon, 30 Aug 2010 15:36:28 -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 <0L7Z0021TLHLJB00@lion.sonnection.nl> for domainrep@ietf.org; Tue, 31 Aug 2010 00:36:58 +0200 (CEST) Message-id: <4C7C3289.2000407@sonnection.nl> Date: Tue, 31 Aug 2010 00:36:57 +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: Nathaniel Borenstein References: <4C779114.3050109@tana.it> <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> In-reply-to: <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> Content-type: multipart/alternative; boundary=------------060906010006020000090605 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1283207818; bh=+8Psew/46kM8dF0fJAtzRJZVjVOG68fHwNW63sepEgE=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=X41Zm0DV8y1IZxPYlP87SKOeRWs97bcy4iZPjyy1MdZiBzY8zB1V/LUV+/4Hak2aG zKbKxwbQguX75z3eHrBw7A1l+TCsVwkGTZpi2mzpDTkSm37LL2GAz+MoE/jncxc+jm ggR4aywnkrR38Kjcm2Jc9YPBQhFnkRiZvLCaLr0w= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L7Z0021TLHLJB00 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: Mon, 30 Aug 2010 22:36:38 -0000 This is a multi-part message in MIME format. --------------060906010006020000090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nathaniel, the model you propose sounds attractive to me, but I'm not sure I understand all the details right now. A few questions: On 08/30/2010 01:57 PM, Nathaniel Borenstein wrote: > Alessandro's "small and larger queries" (minor detail) I believe John was the first one to propose the split between small and large domains/queries. > -- which I like -- seem to point towards a deeper aspect of the > problem, and towards a few simple things we can do to make the > resulting protocol much more generally useful. What I'm about to > suggest doesn't affect most of what we've discussed on this list, only > the structure of the reputation information being passed around. > > Most of us are on this mailing list because we want to use reputations > to attack /email-related /problems. We're inevitably going to worry > primarily about the aspects of reputation that apply to email. We > probably all agree on the need to itemize threat types; we haven't > (yet) all agreed on several other likely things such as organization > types, but they're obviously valid topics to discuss. Still, most of > us want to exclude from our scope the management of reputations for > activities such as kiddie porn, music piracy, aiding terrorists, > swindling consumers, etc. etc. But it's hard to deny that strong > needs for reputation exchange will emerge in all sorts of domains > beyond email. We should at least consider trying to get the basic > idea right in the first place, to make the system potentially reusable > for such purposes. > > 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). +1 > So, I find myself wondering: what is the fundamental unit of > reputation exchange? > > The simplest "reputon" Very nice name! > I can think of -- though I fear I'll shortly learn just how > oversimplistic it is -- looks like this strawman idea: > > AGENT-A (identified with confidence level X) says that AGENT-B has > PERCENTAGE likelihood (with confidence level Y) of ASSERTION. (Some > assertions will probably require encapsulating some arbitrary data as > part of the reputon.) Can you explain more about this 'encapsulating some arbitrary data', possibly provide a use case or an example? > More sophisticated information can be computed by matching multiple > reputons and facts together. The weight we give the above reputon > might depend on another reputon, assessing AGENT-A's value as a > source of reputation information. (Or we might base that assessment > on our own past observations.) Probably our own past observations should be expressed in reputons, to fit nicely into this model? > With the right definition of a reputon, we can easily devise syntax > for using it in the small and large queries. Each application using > the mechanism will define its own values of ASSERTION. (I'm guessing > we need a two-level namespace here.) What two-level namespace do you have in mind? Can you give an example? > I think we have the chance to produce a pretty useful piece of > infrastructure here, at very little (if any) additional cost to us. > It also suggests a divide-and-conquer approach here -- one document > could define a MIME type for reputons, another the overall > architecture for reputation management, two more could define the > small and large query types, and another the specific ASSERTIONs for > email reputations. > > Thoughts? -- Nathaniel It's an interesting model, but as I said, I'm not sure I understand all the details, yet. /rolf --------------060906010006020000090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nathaniel,

the model you propose sounds attractive to me, but I'm not sure I understand all the details right now. A few questions:

On 08/30/2010 01:57 PM, Nathaniel Borenstein wrote:
Alessandro's "small and larger queries"

(minor detail) I believe John was the first one to propose the split between small and large domains/queries.

-- which I like -- seem to point towards a deeper aspect of the problem, and towards a few simple things we can do to make the resulting protocol much more generally useful.  What I'm about to suggest doesn't affect most of what we've discussed on this list, only the structure of the reputation information being passed around.

Most of us are on this mailing list because we want to use reputations to attack email-related problems.  We're inevitably going to worry primarily about the aspects of reputation that apply to email.  We probably all agree on the need to itemize threat types; we haven't (yet) all agreed on several other likely things such as organization types, but they're obviously valid topics to discuss.  Still, most of us want to exclude from our scope the management of reputations for activities such as kiddie porn, music piracy, aiding  terrorists, swindling consumers, etc. etc.  But it's hard to deny that strong needs for reputation exchange will emerge in all sorts of domains beyond email.  We should at least consider trying to get the basic idea right in the first place, to make the system potentially reusable for such purposes.

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

+1

 So, I find myself wondering: what is the fundamental unit of reputation exchange?

The simplest "reputon"

Very nice name!

I can think of -- though I fear I'll shortly learn just how oversimplistic it is -- looks like this strawman idea:

AGENT-A (identified with confidence level X) says that AGENT-B has PERCENTAGE likelihood (with confidence level Y) of ASSERTION.  (Some assertions will probably require encapsulating some arbitrary data as part of the reputon.)

Can you explain more about this 'encapsulating some arbitrary data', possibly provide a use case or an example?

More sophisticated information can be computed by matching multiple reputons and facts together.  The weight we give the above reputon might depend on  another reputon, assessing AGENT-A's value as a source of reputation information.  (Or we might base that assessment on our own past observations.)

Probably our own past observations should be expressed in reputons, to fit nicely into this model?

With the right definition of a reputon, we can easily devise syntax for using it in the small and large queries.  Each application using the mechanism will define its own values of ASSERTION.  (I'm guessing we need a two-level namespace here.)

What two-level namespace do you have in mind? Can you give an example?

 I think we have the chance to produce a pretty useful piece of infrastructure here, at very little (if any) additional cost to us.  It also suggests a divide-and-conquer approach here -- one document could define a MIME type for reputons, another the overall architecture for reputation management, two more could define the small and large query types, and another the specific ASSERTIONs for email reputations.

Thoughts?  -- Nathaniel

It's an interesting model, but as I said, I'm not sure I understand all the details, yet.

/rolf
--------------060906010006020000090605-- From ietf-dkim@kitterman.com Mon Aug 30 16:55:22 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 240CB3A6882 for ; Mon, 30 Aug 2010 16:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_ABOUTYOU=0.5] 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 0Jqelqgg-gNr for ; Mon, 30 Aug 2010 16:55:20 -0700 (PDT) Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by core3.amsl.com (Postfix) with ESMTP id 8B5E83A6859 for ; Mon, 30 Aug 2010 16:55:20 -0700 (PDT) Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id 0969420E40CB; Mon, 30 Aug 2010 19:55:51 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1283212551; bh=HtMeBtqo+sj7Kn3ycr6LikTqAistQdbBfxbcu8qQrVY=; h=References:In-Reply-To:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=ZvdS2Yi52YQX6ZXLAiWu/g2RhOO/kIaDdC++h+680GHS4IaTTXIU2X3yzrDSMwUZY he3mL1Ld4yRvKNxP6BGw4nmQb5gu3FVZ0UbI03h2pr4l0LL7sAJnWr+gdTfLF07lBy A56NIhdGrYmcKh7XZY3t1WagZ5Xh553i8Q/IPTsc= Received: from 137.sub-174-205-130.myvzw.com (137.sub-174-205-130.myvzw.com [174.205.130.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id 1032520E403C; Mon, 30 Aug 2010 19:55:49 -0400 (EDT) X-User-Agent: K-9 Mail for Android References: <4C779114.3050109@tana.it> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> <4C7A6569.7050008@tana.it> <4C7AAAED.5010408@mail-abuse.org> <4C7B9429.3030600@tana.it> <4C7C30C5.3040104@mail-abuse.org> In-Reply-To: <4C7C30C5.3040104@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit From: Scott Kitterman Date: Mon, 30 Aug 2010 19:55:59 -0400 To: domainrep@ietf.org Message-ID: 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: Mon, 30 Aug 2010 23:55:22 -0000 "Douglas Otis" wrote: > On 8/30/10 4:21 AM, Alessandro Vesely wrote: >> On 29/Aug/10 20:46, Douglas Otis wrote: >> >> Including a huge list of trusted vouchers is hard, unless we >> introduce meta-vouchers (looks like pre-loaded X509 certifiers.) > >There may be a confirmation process developed to support a keyassure >public key mechanisms that allows government de-certification, and >confirmation of a domains' physical locations. > Unless methods for determining reputation are part of this effort, this seems not relevant. >> Bad actors could then easily have themselves appear as being in one >> > of these "too important" or "too big" categories. >> >> Not in the FDIC, say. If all vouchers are carefully selected, none >> of them would vouch for unionbanknigeria.net. > >Are you suggesting EV certificates would not be good enough for >exchanging email? Will governments then need to confirm the new >certificate type, and who will pay for the confirmation? This is really up to the reputation provider to get right. I don't see anything to standardize. >> >> IMHO, the service should be provided for free. >> > >> > Do you mean that resource fees should offer adequate enforcement >> > of related agreements? But even that is not really free. On the >> > other hand, a monitoring service as a stop-gap effort will deal >> > with DDoS attack and lawsuits, whose defense requires adequate >> > funding. Or said another way, you don't get what you don't pay >> > for. >> >> If it is my network provider, a national institution, or similar, >> resources are already paid for. An private independent service will >> have difficulties in gaining credibility; however, if it manages to >> do that business, they may charge some amount for /querying/, not for >> vouching. (Spamhaus won't take money to unlist addresses.) > >Okay, we agree service subscriptions might be used. This then requires >a means to enforce query behavior and subscription payments, or more >generally, a mechanism is needed to exclude non-subscribers or bad-actors. Why is more mechanism needed for domain reputation than. IP reputation? There are plenty of crap RBLs out there and good admins learn to avoid them. >> >> For email, a DKIM-signed abusive message inside a DKIM-signed >> >> abuse report can be assimilated to an incident, unless the >> >> original sender contests. Yet, incidents should not directly >> >> affect a domain's reputation. It is the /domain response/ to the >> >> incident that matters. >> > >> > Disagree. There is nothing preventing bad actors from inundating >> > the Internet with any domain's DKIM messages. A bad actor could >> > obtain a Yahoo account, send themselves their spammy messages, and >> > then replay them throughout the Internet. Should a domain abused by >> > a monitoring service who wrongly holds a DKIM domain responsible >> > for the actions of an unknown SMTP client really be expected to >> > contest each injustice? >> >> Yahoo should fire that account, as a response. Their policy for >> getting new accounts being what it is, they may have to do it several >> times. > >So what if they do? Even accounts promptly disabled will not halt >distributions of replayed messages, nor will rate limiting user accounts >offer protection from replay abuse. A feature of DKIM is that a message >can be redirected anywhere. DKIM domains can not be expected to contest >each injustice of being wrongly accused of having assigned a message >destination. They can and they will. If you sign a message, you take responsibility. >> For the mechanics of replaying, you're right: DKIM signatures /alone/ >> do not attest the legitimacy of a message. > >A DKIM domain does not identify who assigned the destination for an >unsolicited message, especially when adopting a principle that >assessment MUST allow domains a means to defend their reputation. A >bad-actor will not need to be a user of the domain to replay messages. >The SMTP client domain, and not the DKIM domain, MUST be used to >establish reputations based upon receipt of unsolicited messages. DKIM signing domain will be one input into reputation because signing a message is taking responsibility for it. >> > What happens when the DKIM domain responds with a request to stop >> > sending the abusive reports! Would this then allow the monitoring >> > service to report the DKIM domain as unresponsive and a bad >> > domain? >> >> Reports should never be abusive, since they should only be shared by >> trusting parties. However, they can be sent by error, or in response >> to an attack. > >Reports should always be directed to a domain verified as having issued >the message to the recipient. DKIM does not offer such verification. >It is not right to say since most messages are not replayed, it is safe >to assume a message was not replayed when assessing reputations or when >deciding where to send notifications. You know what they say about >making assumptions... Yes. It's probably a bad idea to assume reputation providers will care if a signing domain tries to avoid responsibility for messages they've signed by claiming they were replayed. >> > Bad actors can indicate they trust their hundreds of thousands of >> > 0wned systems. They can say bad things about your domain and >> > replicate what has been said about the others, including their own >> > which they will have managed to skew. They then send you a friendly >> > message indicating they can improve your domains rating, at a >> > moderate fee. >> >> Yeah, they also send 419 opportunities :-) > >It is also difficult to detect and remove all outbound messages offering >drugs, software, nude pictures of hot celebrities, undelivered packages, >politicians caught in the act, claiming someone sent a large amount of >spam, or that someone failed to pay for a service. Any such message >might be replayed and used to entice victims into visiting malicious >drive-by websites. At the same time, one of their ten of thousands of >0wned systems can also apply for new accounts, while granting access to >pornography for those solving forwarded captchas. To the extent entities do well at this, they will have good reputations. To the extent they don't, they won't. >> > Scaling trust on a free basis is something bot-nets are good at >> > gaming. Time to put away the tie-dyed shirt, the era of free-trust >> > is over. :^) >> >> Despite banks often abusing that term, "trust" cannot really be >> bought, nor sold. > >Certificates, vouching, and CA services are being bought and sold >because people feel they can trust this information. The results of a >searching service are intended to indicate where people are referencing >a specific topic. Unfortunately, bot-nets continuously demonstrate a >skill at corrupting search results obtained from the community. A large >number of anything is progressively becoming less meaningful. Low quality aggregation is not helpful. They key is for providers to do it well, but that's not very related to anything that can be standardized. >> Even if we decide that we won't implement a web of trust, we should >> strive to avoid standardizing models that preclude it, if at all >> possible. > >No matter how reputation information is distributed, evidence supporting >reputations MUST NOT be based upon any assumption of involvement. >Holding an entity accountable for an unsolicited message means no >assumptions regarding who assigned the destination can be allowed. >Otherwise, bad-actors can quickly make such a system untrustworthy, >disruptive, and wholly unfair. > It's up to reputation providers to work out how to do this and not a subject for standardization. Scott K From stephen.farrell@cs.tcd.ie Tue Aug 31 00:17:55 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 5C8883A68A3 for ; Tue, 31 Aug 2010 00:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.823 X-Spam-Level: X-Spam-Status: No, score=-102.823 tagged_above=-999 required=5 tests=[AWL=-0.224, 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 gShzr2iREiUv for ; Tue, 31 Aug 2010 00:17:54 -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 03A823A68AD for ; Tue, 31 Aug 2010 00:17:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DE5C43E4085; Tue, 31 Aug 2010 08:18:21 +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=1283239101; bh=gsb2mcqael4Z0h 8/lBQ03drxOcipuLSxDsy24B0hHXI=; b=Y6N9oK1kDfrCQT+8iOQ8LYLKzf71Bt OtZJpEDEnwjfK17jJAAc6jdshtFyvFjEF/eGuN3un1aB+fiyHiWl0cDUJUhpa1zk e9kTtSDWnK1Ay27Lx/fxsxTVVOveivmq92DANiKCGhyGpRgg5jdEj66I7zfvwXSm qu8zlaXWAr29SA+xLcXyZy3ImIH+zlbo+3aKwITIJDaXi76U9mTEqruQ8VVW52Ej 4WIMzFIfd+eVNip+4Sl6Lh6EoUMxC1MgmKE3FtMWnAEoJVonVf2Iotp5uEanVACm jmZDwgLMwswWexLyyenw6vCqcW8nozhcxYzqTEURTe+gmwYL7mbFRQoQ== 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 bR657LNzvF-6; Tue, 31 Aug 2010 08:18:21 +0100 (IST) Received: from [10.87.48.3] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 706163E407B; Tue, 31 Aug 2010 08:18:21 +0100 (IST) Message-ID: <4C7CACBC.20607@cs.tcd.ie> Date: Tue, 31 Aug 2010 08:18:20 +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> In-Reply-To: <4C7C2A72.5070701@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: Tue, 31 Aug 2010 07:17:55 -0000 On 30/08/10 23:02, Rolf E. Sonneveld wrote: > Hi, all > > as promised, in addition to the list of (tentative) requirements, sent > to this list by Alessandro, I have tried to gather information from the > discussions about 'scope'. 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. For a DNS based solution, that can be achieved to an acceptable level for free or nearly free, 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.) S. From nsb@guppylake.com Tue Aug 31 11:23:53 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 77E7C3A69B8 for ; Tue, 31 Aug 2010 11:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.622 X-Spam-Level: X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[AWL=0.621, BAYES_50=0.001] 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 DIe-VVgybaWX for ; Tue, 31 Aug 2010 11:23:51 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by core3.amsl.com (Postfix) with ESMTP id 892183A69B0 for ; Tue, 31 Aug 2010 11:23:51 -0700 (PDT) Received: from 184-205-25-159.pools.spcsdns.net ([184.205.25.159] helo=[192.168.0.196]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1OqViZ-00068q-23; Tue, 31 Aug 2010 14:38:00 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4C7C3289.2000407@sonnection.nl> Date: Tue, 31 Aug 2010 14:24:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C779114.3050109@tana.it> <6F12B38C-F066-4729-9440-55CDD769C355@guppylake.com> <4C7C3289.2000407@sonnection.nl> To: Rolf E. Sonneveld 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: Tue, 31 Aug 2010 18:23:53 -0000 On Aug 30, 2010, at 6:36 PM, Rolf E. Sonneveld wrote: > (minor detail) I believe John was the first one to propose the split = between small and large domains/queries. Oops, sorry. If the Internet were a crime scene John would be in = trouble, his prints are all over it. :-) >> AGENT-A (identified with confidence level X) says that AGENT-B has = PERCENTAGE likelihood (with confidence level Y) of ASSERTION. (Some = assertions will probably require encapsulating some arbitrary data as = part of the reputon.) >=20 > Can you explain more about this 'encapsulating some arbitrary data', = possibly provide a use case or an example? Sure. The intent of my model -- which so far exists only in the fuzzy = logic of my brain -- was to make the reputon the simplest, most generic = expression of reputation data possible. Then, the act of defining each = ASSERTION would define the contents of the arbitrary MIME entity that = accompanies the reputon. What I see as the strength of this approach is that we don't have to = argue so much about what kind of data gets included in the general case; = additional data will be defined for each assertion So, in the case of rating email sources, we might want to talk about a = reputation for sending spam, and such a reputation might be more useful = if accompanied by the date range for which spamming was evidenced. In = this case, the appended data would include those date ranges, iin a = format specified as part of the definition of the assertion. Or, for = the assertion that a domain is sourcing email that contains viruses, the = attached data might include a description of the type of virus. Or not. The point is that we won't have to argue about these details = globally, but in specific contexts where it's easier to see if something = is useful. >> More sophisticated information can be computed by matching multiple = reputons and facts together. The weight we give the above reputon might = depend on another reputon, assessing AGENT-A's value as a source of = reputation information. (Or we might base that assessment on our own = past observations.) >=20 > Probably our own past observations should be expressed in reputons, to = fit nicely into this model? I think that's an implementation question. If I had a good symbolic = logic system, I might consider translating the reputons into its syntax = instead. But I think most uses will be far too simple to require such a = system. On the other hand, if this catches on, I can certainly imagine = some logic engines operating on them directly. >> With the right definition of a reputon, we can easily devise syntax = for using it in the small and large queries. Each application using the = mechanism will define its own values of ASSERTION. (I'm guessing we = need a two-level namespace here.) >=20 > What two-level namespace do you have in mind? Can you give an example? I almost wrote "at least two-level" actually, because I'm increasingly = thinking about three levels. I was imagining letting anyone with an = application define reputation assertions for that application, with = domain names used to prevent naming conflicts. And it might make sense = to help those domains support multiple applications with more than a = one-level name space, so I'd consider including a general category name = like email, yielding something like: consumer-report.com/dentists/is-liberal-with-nitrous-oxide or ietf.org/email/uses-punctuation-sloppily In the latter case, the IETF would own the namespace, make its own = decisions about the category names, and have a mechanism for publishing = the definition of the assertion. =20 In a nutshell: I'm trying to decouple the definition of what you're = asserting from the mechanism by which you assert it. -- Nathaniel From R.E.Sonneveld@sonnection.nl Tue Aug 31 15:04:46 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 1B9F33A6855 for ; Tue, 31 Aug 2010 15:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.091 X-Spam-Level: X-Spam-Status: No, score=-3.091 tagged_above=-999 required=5 tests=[AWL=-1.587, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 zN5kP1qh3PeX for ; Tue, 31 Aug 2010 15:04:45 -0700 (PDT) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by core3.amsl.com (Postfix) with ESMTP id E2E763A6858 for ; Tue, 31 Aug 2010 15:04:44 -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 <0L8100526EOQIL00@lion.sonnection.nl> for domainrep@ietf.org; Wed, 01 Sep 2010 00:05:14 +0200 (CEST) Message-id: <4C7D7C99.3000000@sonnection.nl> Date: Wed, 01 Sep 2010 00:05:13 +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: Stephen Farrell References: <4C7C2A72.5070701@sonnection.nl> <4C7CACBC.20607@cs.tcd.ie> In-reply-to: <4C7CACBC.20607@cs.tcd.ie> Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1283292314; bh=TezvXvQqidJVuLAmTwYKRopf6jZjqR5+r445ueND79k=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=k3A5MBLPwS29U6M3phiN3eLRSjcya2+OSrTVTe/FBipogy03Ltc/oj/qYpmMiCcfE W2WLCjpwu6pzJm3TGOMIisKhxrMIhJMxv0rLK3l6eic0UuwSW5mi/Q/cDAavugJkXZ QvaGss5tD5auVmJJAtUNmPAWtoGiwrvhOwG/qfXo= X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L8100526EOQIL00 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: Tue, 31 Aug 2010 22:04:46 -0000 On 08/31/2010 09:18 AM, Stephen Farrell wrote: > > On 30/08/10 23:02, Rolf E. Sonneveld wrote: >> Hi, all >> >> as promised, in addition to the list of (tentative) requirements, sent >> to this list by Alessandro, I have tried to gather information from the >> discussions about 'scope'. > 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. That's a good one! I believe this has not been discussed before on this list and you're the first here to mention it. IMO this requirement is definitely in scope and is important enough to be included in a document about domain reputation. > For a DNS based solution, that can be achieved to an acceptable > level for free or nearly free, Can you elaborate? > 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. /rolf From jdfalk-lists@cybernothing.org Tue Aug 31 15:31: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 456C33A6898 for ; Tue, 31 Aug 2010 15:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2s2Y6laF5Tl2 for ; Tue, 31 Aug 2010 15:31:04 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 6491B3A6876 for ; Tue, 31 Aug 2010 15:30:59 -0700 (PDT) Received: from rpca-cmalchow.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7VMVRdi002776 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 31 Aug 2010 15:31:29 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7VMVRdi002776 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1283293889; bh=Mydui4w0tYSecG4E9VEoHML/0p8Q1Fo72cAcGGqII Uc=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=JVIhcRGUa9cSI6XX e6A+stBGbQ1Z+APWtJPOtzvzTkzk5t6phs1x53/Tq4ZYYnUAYhwc0Rmpw25Zhdm/Wy8 kGO8zqOZuzKb2rl+1COmXPZGIoELUnphzVLgMW3l1cXhDvlU50ePfLl8LgIcxRcBub/ +w5z2v2AiK6QUFCBzd+Qw= References: <4C7C2A72.5070701@sonnection.nl> In-Reply-To: <4C7C2A72.5070701@sonnection.nl> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 Message-Id: Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 31 Aug 2010 15:31: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: Tue, 31 Aug 2010 22:31:06 -0000 (as participant) On Aug 30, 2010, at 3:02 PM, Rolf E. Sonneveld wrote: > =95 is the way Domain Reputation Providers exchange their = reputation information (between Domain Reputation Providers) in scope? = Some say 'yes', but isn't that adding a complexity factor? Why would it be different from the way a Domain Reputation Provider = gives information to any other querant? > =95 is the following question in scope, or out scope: > if the unit of reputation c.q. the granularity of reputation is a = single domainname, how can reputations be differentiated between = different web pages within the same domain (e.g. big ISP or ESP or = content provider); a similar question can be asked about differentiating = between reputations of mail addresses within a domain. Is this = discussion in scope? If the identifier is a domain name construct, then those would be out of = scope. If we're talking about any random text string that might = possibly be construed to be an identifier, then they'd be in scope. I'd = prefer the former, because it seems far more achievable and has = immediate value. From jdfalk-lists@cybernothing.org Tue Aug 31 15:32:26 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 CA14C3A68A5 for ; Tue, 31 Aug 2010 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45Neq6kKKAZo for ; Tue, 31 Aug 2010 15:32:23 -0700 (PDT) Received: from ocelope.disgruntled.net (ocelope.disgruntled.net [97.107.131.76]) by core3.amsl.com (Postfix) with ESMTP id 0BA793A6872 for ; Tue, 31 Aug 2010 15:32:22 -0700 (PDT) Received: from rpca-cmalchow.rpcorp.local ([12.180.99.220]) (authenticated bits=0) by ocelope.disgruntled.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7VMWpwh002798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 31 Aug 2010 15:32:53 -0700 X-DKIM: Sendmail DKIM Filter v2.6.0 ocelope.disgruntled.net o7VMWpwh002798 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cybernothing.org; s=triac; t=1283293973; bh=m0azpyW23F3yKbuhmW29BPXn/5Eu8LVQLqxc247mY Qw=; h=References:In-Reply-To:Mime-Version:Content-Type:Message-Id: Content-Transfer-Encoding:From:Subject:Date:To; b=I6zha7ugU1j839bg RkENY4+Ul+4/8n5/JKqRkvl4e8L5oRJBSFgFJ2esCnGmtyst4BSLR0bJRrNGyjmhUE2 volJmHC9yDNtby55K0fTv/t53fTsTFGtttg4kyHJMfh/tISe5MVhJEMEc14QeWbGMwe tLvB5e8QLvgVnb5Lbe5CQ= References: <4C7C2A72.5070701@sonnection.nl> <4C7CACBC.20607@cs.tcd.ie> In-Reply-To: <4C7CACBC.20607@cs.tcd.ie> Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Message-Id: <7AF4EB39-F4F1-4C62-8510-99D758C4C1EF@cybernothing.org> Content-Transfer-Encoding: quoted-printable From: "J.D. Falk" Date: Tue, 31 Aug 2010 15:32:46 -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: Tue, 31 Aug 2010 22:32:26 -0000 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? From dotis@mail-abuse.org Tue Aug 31 15:39:34 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 45F323A6839 for ; Tue, 31 Aug 2010 15:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.949 X-Spam-Level: X-Spam-Status: No, score=-104.949 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_50=0.001, 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 0o3jZUs+vX0P for ; Tue, 31 Aug 2010 15:39:32 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id BA84C3A681F for ; Tue, 31 Aug 2010 15:39:32 -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 390A6A94459 for ; Tue, 31 Aug 2010 22:39:59 +0000 (UTC) Message-ID: <4C7D84BF.5060101@mail-abuse.org> Date: Tue, 31 Aug 2010 15:39:59 -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> <4C786C32.6060304@mail-abuse.org> <4C78E4A2.20105@tana.it> <4C79B3CA.3040006@mail-abuse.org> <4C7A6569.7050008@tana.it> <4C7AAAED.5010408@mail-abuse.org> <4C7B9429.3030600@tana.it> <4C7C30C5.3040104@mail-abuse.org> 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: Tue, 31 Aug 2010 22:39:34 -0000 On 8/30/10 4:55 PM, Scott Kitterman wrote: > "Douglas Otis" wrote: >> On 8/30/10 4:21 AM, Alessandro Vesely wrote: >>> On 29/Aug/10 20:46, Douglas Otis wrote: >>> >>> Including a huge list of trusted vouchers is hard, unless we >>> introduce meta-vouchers (looks like pre-loaded X509 certifiers.) >> There may be a confirmation process developed to support a keyassure >> public key mechanisms that allows government de-certification, and >> confirmation of a domains' physical locations. > Unless methods for determining reputation are part of this effort, this seems not relevant. Scott, Criminal activity authenticated by a certificate provides a fairly solid basis for authorities to then demand removal of the certificate along with the related domain. This function needs to be part of any public key scheme using DNS, where immediate removal would not be otherwise possible. Most domain exploitations begin and end within a few hours. Such a removal list could also make reputation services unneeded. >>> Bad actors could then easily have themselves appear as being in one >>>> of these "too important" or "too big" categories. >>> Not in the FDIC, say. If all vouchers are carefully selected, none >>> of them would vouch for unionbanknigeria.net. >> Are you suggesting EV certificates would not be good enough for >> exchanging email? Will governments then need to confirm the new >> certificate type, and who will pay for the confirmation? > This is really up to the reputation provider to get right. I don't see anything to standardize. So reputation erects a barrier high enough to get everyone paying for the added efforts? First start by getting everyone to properly authenticate their domain. Why not simply use TLS with a EV cert with SMTP clients and call it done? Why would there be a need for reputations at that point, since promptly and proactively responding to criminal activity would be expected, would it not? >> Okay, we agree service subscriptions might be used. This then requires >> a means to enforce query behavior and subscription payments, or more >> generally, a mechanism is needed to exclude non-subscribers or bad-actors. > Why is more mechanism needed for domain reputation than IP reputation? There are plenty of crap RBLs out there and good admins learn to avoid them. Sorry, this must not have been said clearly enough. The service needs a way to indicate "service is being refused", without causing some other problem, where refusal also needs to occur at the initial stages. >> So what if they do? Even accounts promptly disabled will not halt >> distributions of replayed messages, nor will rate limiting user accounts >> offer protection from replay abuse. A feature of DKIM is that a message >> can be redirected anywhere. DKIM domains can not be expected to contest >> each injustice of being wrongly accused of having assigned a message >> destination. > They can and they will. If you sign a message, you take responsibility. A domain applying DKIM can only take responsibility for the signed portion of the message. DKIM does NOT affirm the destination or return path of the message, which means DKIM domains can not be held responsible for the sending of unsolicited email, since a DKIM signature does not affirm the signing domain's involvement in this abusive act. >> A DKIM domain does not identify who assigned the destination for an >> unsolicited message, especially when adopting a principle that >> assessment MUST allow domains a means to defend their reputation. A >> bad-actor will not need to be a user of the domain to replay messages. >> The SMTP client domain, and not the DKIM domain, MUST be used to >> establish reputations based upon receipt of unsolicited messages. > DKIM signing domain will be one input into reputation because signing a message is taking responsibility for it. 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. 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? 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? >> Reports should always be directed to a domain verified as having issued >> the message to the recipient. DKIM does not offer such verification. >> It is not right to say since most messages are not replayed, it is safe >> to assume a message was not replayed when assessing reputations or when >> deciding where to send notifications. You know what they say about >> making assumptions... > Yes. It's probably a bad idea to assume reputation providers will care if a signing domain tries to avoid responsibility for messages they've signed by claiming they were replayed. Are you suggesting reputation services can ignore the domain of the MTA issuing abusive messages, whenever they find it easier to use questionable message content to make baseless assumptions about the source of a message? Such a service could easily find themselves facing serious consequences for such negligent assumptions. A bad-actor is able to violate any relationship normally seen between various message elements. Having signed a message does not mean the domain intended the destination of the message where it was not wanted, nor does having authorized a server mean this domain originated the message. >> It is also difficult to detect and remove all outbound messages offering >> drugs, software, nude pictures of hot celebrities, undelivered packages, >> politicians caught in the act, claiming someone sent a large amount of >> spam, or that someone failed to pay for a service. Any such message >> might be replayed and used to entice victims into visiting malicious >> drive-by websites. At the same time, one of their ten of thousands of >> 0wned systems can also apply for new accounts, while granting access to >> pornography for those solving forwarded captchas. > To the extent entities do well at this, they will have good reputations. To the extent they don't, they won't. Having written some of these filters, it is very difficult to block more than 97% of messages created by clever bad actors. While the filter might block a high percentage of outbound abusive messages, those that slipped past will have also been vetted as difficult to detect and become good candidates for being replayed a million-fold. No one can ever filter outbound messages well enough to protect their reputation whenever DKIM domains become a basis for acceptance and are held accountable for the uncontrolled destination of the message. In other words, this scheme will fail. >> Certificates, vouching, and CA services are being bought and sold >> because people feel they can trust this information. The results of a >> searching service are intended to indicate where people are referencing >> a specific topic. Unfortunately, bot-nets continuously demonstrate a >> skill at corrupting search results obtained from the community. A large >> number of anything is progressively becoming less meaningful. > Low quality aggregation is not helpful. They key is for providers to do it well, but that's not very related to anything that can be standardized. While I often use several different search engines, none of these services seem able to prevent results from being incredibly skewed. There is even an underground industry working at corrupting these services. >> No matter how reputation information is distributed, evidence supporting >> reputations MUST NOT be based upon any assumption of involvement. >> Holding an entity accountable for an unsolicited message means no >> assumptions regarding who assigned the destination can be allowed. >> Otherwise, bad-actors can quickly make such a system untrustworthy, >> disruptive, and wholly unfair. > It's up to reputation providers to work out how to do this and not a subject for standardization. Why would it be wrong to suggest domains being held accountable need to be authenticated when counting incidents that might negatively affect a domain's ability to conduct commerce. Are you suggesting there are no standards or methods to authenticate a domain? Frankly, IPv6 will soon make most IP address related methods impractical, so we should be working earnestly at developing standards needed to authenticate SMTP client domains that can be held accountable for the entirety of a message issued publicly on port 25. -Doug From ietf-dkim@kitterman.com Tue Aug 31 16:05: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 CE6033A68B5 for ; Tue, 31 Aug 2010 16:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.08 X-Spam-Level: X-Spam-Status: No, score=-4.08 tagged_above=-999 required=5 tests=[AWL=-1.481, 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 VZ7b+6DHgOqw for ; Tue, 31 Aug 2010 16:05:18 -0700 (PDT) Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by core3.amsl.com (Postfix) with ESMTP id 95A373A68A5 for ; Tue, 31 Aug 2010 16:05:18 -0700 (PDT) Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id AF2B638C0BC; Tue, 31 Aug 2010 19:05:48 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1283295948; bh=EslIdQHZw9jG30loFNQnJCHSujv8Ouk9Hbw1eA0vkuU=; h=From:To:Subject:Date:References:In-Reply-To:MIME-Version: Content-Type:Content-Transfer-Encoding:Message-Id; b=LrcedoqKB6nZDF8eFXxFuv0k49zg88AYU1pQq/GKWcKmqbePZ43EXoUtoheDOu8TO iDXopyc2+ZbQEK/3xBJYonts6bpzaO1g2Rx3mukqxGP2cqS2RvGbF+joA9rMZRzyYv pOLmldrAerze5nO0FnrrqoKbKwo/hy4WMflHN+6o= From: Scott Kitterman To: domainrep@ietf.org Date: Tue, 31 Aug 2010 19:05:46 -0400 User-Agent: KMail/1.13.2 (Linux/2.6.32-24-generic; KDE/4.4.2; i686; ; ) References: <4C779114.3050109@tana.it> <4C7D84BF.5060101@mail-abuse.org> In-Reply-To: <4C7D84BF.5060101@mail-abuse.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201008311905.47118.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: Tue, 31 Aug 2010 23:05:20 -0000 On Tuesday, August 31, 2010 06:39:59 pm Douglas Otis wrote: > On 8/30/10 4:55 PM, Scott Kitterman wrote: > > "Douglas Otis" wrote: > >> On 8/30/10 4:21 AM, Alessandro Vesely wrote: > >>> On 29/Aug/10 20:46, Douglas Otis wrote: > >>> > >>> Including a huge list of trusted vouchers is hard, unless we > >>> introduce meta-vouchers (looks like pre-loaded X509 certifiers.) > >> > >> There may be a confirmation process developed to support a keyassure > >> public key mechanisms that allows government de-certification, and > >> confirmation of a domains' physical locations. > > > > Unless methods for determining reputation are part of this effort, this > > seems not relevant. > > Scott, > > Criminal activity authenticated by a certificate provides a fairly solid > basis for authorities to then demand removal of the certificate along > with the related domain. This function needs to be part of any public > key scheme using DNS, where immediate removal would not be otherwise > possible. Most domain exploitations begin and end within a few hours. > Such a removal list could also make reputation services unneeded. Which reinforces my point that it's not related to this effort. > >>> Bad actors could then easily have themselves appear as being in one > >>>> > >>>> of these "too important" or "too big" categories. > >>> > >>> Not in the FDIC, say. If all vouchers are carefully selected, none > >>> of them would vouch for unionbanknigeria.net. > >> > >> Are you suggesting EV certificates would not be good enough for > >> exchanging email? Will governments then need to confirm the new > >> certificate type, and who will pay for the confirmation? > > > > This is really up to the reputation provider to get right. I don't see > > anything to standardize. > > So reputation erects a barrier high enough to get everyone paying for > the added efforts? First start by getting everyone to properly > authenticate their domain. > > Why not simply use TLS with a EV cert with SMTP clients and call it > done? Why would there be a need for reputations at that point, since > promptly and proactively responding to criminal activity would be > expected, would it not? No. > >> Okay, we agree service subscriptions might be used. This then requires > >> a means to enforce query behavior and subscription payments, or more > >> generally, a mechanism is needed to exclude non-subscribers or > >> bad-actors. > > > > Why is more mechanism needed for domain reputation than IP reputation? > > There are plenty of crap RBLs out there and good admins learn to avoid > > them. > > Sorry, this must not have been said clearly enough. The service needs > a way to indicate "service is being refused", without causing some other > problem, where refusal also needs to occur at the initial stages. > > >> So what if they do? Even accounts promptly disabled will not halt > >> distributions of replayed messages, nor will rate limiting user accounts > >> offer protection from replay abuse. A feature of DKIM is that a message > >> can be redirected anywhere. DKIM domains can not be expected to contest > >> each injustice of being wrongly accused of having assigned a message > >> destination. > > > > They can and they will. If you sign a message, you take responsibility. > > A domain applying DKIM can only take responsibility for the signed > portion of the message. DKIM does NOT affirm the destination or return > path of the message, which means DKIM domains can not be held > responsible for the sending of unsolicited email, since a DKIM signature > does not affirm the signing domain's involvement in this abusive act. No. It actually doesn't mean that at all. > >> A DKIM domain does not identify who assigned the destination for an > >> unsolicited message, especially when adopting a principle that > >> assessment MUST allow domains a means to defend their reputation. A > >> bad-actor will not need to be a user of the domain to replay messages. > >> The SMTP client domain, and not the DKIM domain, MUST be used to > >> establish reputations based upon receipt of unsolicited messages. > > > > DKIM signing domain will be one input into reputation because signing a > > message is taking responsibility for it. > > 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. 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? > > 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? 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. > >> Reports should always be directed to a domain verified as having issued > >> the message to the recipient. DKIM does not offer such verification. > >> It is not right to say since most messages are not replayed, it is safe > >> to assume a message was not replayed when assessing reputations or when > >> deciding where to send notifications. You know what they say about > >> making assumptions... > > > > Yes. It's probably a bad idea to assume reputation providers will care if > > a signing domain tries to avoid responsibility for messages they've > > signed by claiming they were replayed. > > Are you suggesting reputation services can ignore the domain of the MTA > issuing abusive messages, whenever they find it easier to use > questionable message content to make baseless assumptions about the > source of a message? Such a service could easily find themselves facing > serious consequences for such negligent assumptions. > > A bad-actor is able to violate any relationship normally seen between > various message elements. Having signed a message does not mean the > domain intended the destination of the message where it was not wanted, > nor does having authorized a server mean this domain originated the > message. I'm suggesting that people will consider signing domain from DKIM as an input into their reputation calculations since that's been advertised as it's primary use, but, once again, that's up to reputation providers to figure out and not subject to standardization. > >> It is also difficult to detect and remove all outbound messages offering > >> drugs, software, nude pictures of hot celebrities, undelivered packages, > >> politicians caught in the act, claiming someone sent a large amount of > >> spam, or that someone failed to pay for a service. Any such message > >> might be replayed and used to entice victims into visiting malicious > >> drive-by websites. At the same time, one of their ten of thousands of > >> 0wned systems can also apply for new accounts, while granting access to > >> pornography for those solving forwarded captchas. > > > > To the extent entities do well at this, they will have good reputations. > > To the extent they don't, they won't. > > Having written some of these filters, it is very difficult to block more > than 97% of messages created by clever bad actors. While the filter > might block a high percentage of outbound abusive messages, those that > slipped past will have also been vetted as difficult to detect and > become good candidates for being replayed a million-fold. No one can > ever filter outbound messages well enough to protect their reputation > whenever DKIM domains become a basis for acceptance and are held > accountable for the uncontrolled destination of the message. In other > words, this scheme will fail. Then such reputations won't be usable in the real world and reputation providers will have to figure out a better way to do it. In the mean time, that's really up to them to figure out and not something we can standarize around. > >> Certificates, vouching, and CA services are being bought and sold > >> because people feel they can trust this information. The results of a > >> searching service are intended to indicate where people are referencing > >> a specific topic. Unfortunately, bot-nets continuously demonstrate a > >> skill at corrupting search results obtained from the community. A large > >> number of anything is progressively becoming less meaningful. > > > > Low quality aggregation is not helpful. They key is for providers to do > > it well, but that's not very related to anything that can be > > standardized. > > While I often use several different search engines, none of these > services seem able to prevent results from being incredibly skewed. > There is even an underground industry working at corrupting these services. We see in the IP reputation space plenty of examples of poorly run RBLs and a relative few that are really high quality and suitable for broad production use. I expect that domain reputation will be similar, but trying to judge which reputation providers are good and which are bad is not something that can or should be centralized. You may or may not be right, but I don't think it's anything to do with this discussion. > >> No matter how reputation information is distributed, evidence supporting > >> reputations MUST NOT be based upon any assumption of involvement. > >> Holding an entity accountable for an unsolicited message means no > >> assumptions regarding who assigned the destination can be allowed. > >> Otherwise, bad-actors can quickly make such a system untrustworthy, > >> disruptive, and wholly unfair. > > > > It's up to reputation providers to work out how to do this and not a > > subject for standardization. > > Why would it be wrong to suggest domains being held accountable need to > be authenticated when counting incidents that might negatively affect a > domain's ability to conduct commerce. Are you suggesting there are no > standards or methods to authenticate a domain? Frankly, IPv6 will soon > make most IP address related methods impractical, so we should be > working earnestly at developing standards needed to authenticate SMTP > client domains that can be held accountable for the entirety of a > message issued publicly on port 25. I think that there is more than one way to do it and there is not any body of public experience on how best to do this. It's pretty clear that the how of domain reputation calculation will remain largely private for some time, so there's no point in wasting time on standardizing pieces of it now. Scott K From dotis@mail-abuse.org Tue Aug 31 16:32:38 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 166E43A6884 for ; Tue, 31 Aug 2010 16:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.237 X-Spam-Level: X-Spam-Status: No, score=-106.237 tagged_above=-999 required=5 tests=[AWL=0.362, 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 jNRFgYk9Pt2R for ; Tue, 31 Aug 2010 16:32:36 -0700 (PDT) Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 249BA3A6870 for ; Tue, 31 Aug 2010 16:32:35 -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 ADADEA94621 for ; Tue, 31 Aug 2010 23:33:00 +0000 (UTC) Message-ID: <4C7D912D.3090802@mail-abuse.org> Date: Tue, 31 Aug 2010 16:33:01 -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> <4C7D7C99.3000000@sonnection.nl> In-Reply-To: <4C7D7C99.3000000@sonnection.nl> 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: Tue, 31 Aug 2010 23:32:38 -0000 On 8/31/10 3:05 PM, Rolf E. Sonneveld wrote: > On 08/31/2010 09:18 AM, Stephen Farrell wrote: >> On 30/08/10 23:02, Rolf E. Sonneveld wrote: >>> Hi, all >>> >>> as promised, in addition to the list of (tentative) requirements, sent >>> to this list by Alessandro, I have tried to gather information from the >>> discussions about 'scope'. >> 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. > > That's a good one! I believe this has not been discussed before on > this list and you're the first here to mention it. IMO this > requirement is definitely in scope and is important enough to be > included in a document about domain reputation. Well, it has been, but perhaps only in passing. http://www.ietf.org/mail-archive/web/domainrep/current/msg00179.html >> For a DNS based solution, that can be achieved to an acceptable >> level for free or nearly free, > > Can you elaborate? For an example see: ftp://ftp.isc.org/isc/dnsrpz/isc-tn-2010-1.txt Sharing this type of information would be a way to quickly remove threats published in DNS. This seems inexpensive in terms of resources and performance, and a need to modify existing applications and services. >> 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. There is a substantial difference between responding to query for any domain, or responding to a specific category of domains. And an even bigger difference when responding to specific categories of URIs, where a fair percentage will not fit within a DNS query. Often the round trip needed to establish TCP connections is considered an undesirable overhead which seems to suggest that only information within a very limited category of domains can be collected. Such as domains not yet taken down by authorities currently engaged in criminal activity such as the distribution of malware, or phishing of unwary victims. -Doug