The proposed agenda and slides for the BoF are now available = here:

http://www= .trusteddomain.org/REPUTE%20BoF.pdf

Comments welcome.

-MSK=

From: domainrep-boun= ces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Murray= S. Kucherawy
Sent: Thursday, June 30, 2011 12:36 PM
To: domainrep@ietf.org
Subject: [domainrep] Preliminary agenda, BoF= scheduled

= ;

The preliminary agenda for IETF 81 has been= posted, and we have a BoF scheduled for Monday afternoon. If you won= ’t be there in person then I would encourage you to be in the jabber = room (details will be posted later) so we can gauge interest and seek some = commitments for who’s willing to work on what and bang out a potentia= l charter.

Thanks go out to those who’ve posted already making part= icipation commitments. See you in Quebec City!

-MSK

<= /div>

= --_000_F5833273385BB34F99288B3648C4F06F134EBC4B99EXCHC2corpclo_-- From dhc@dcrocker.net Wed Jul 6 13:20:39 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC9F21F8BBB for ; Wed, 6 Jul 2011 13:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPY9diyO8N9F for ; Wed, 6 Jul 2011 13:20:37 -0700 (PDT) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E84FD21F8BB0 for ; Wed, 6 Jul 2011 13:20:36 -0700 (PDT) Received: from [192.168.1.156] (adsl-67-124-149-98.dsl.pltn13.pacbell.net [67.124.149.98]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id p66KKVFd010596 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 6 Jul 2011 13:20:36 -0700 Message-ID: <4E14C38C.8080905@dcrocker.net> Date: Wed, 06 Jul 2011 13:20:28 -0700 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 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 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 06 Jul 2011 13:20:36 -0700 (PDT) Subject: Re: [domainrep] Preliminary agenda, BoF scheduled X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 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, 06 Jul 2011 20:20:40 -0000 Hi. Mr. Monkeywrench, here... On 7/6/2011 12:09 PM, Murray S. Kucherawy wrote: > The proposed agenda and slides for the BoF are now available here: I think that a component that is currently missing is a variant of an item explicitly prohibited by the draft charter: > * Specific actions to be taken in response to a reputation reply. > It is up to assessors (i.e., the consumers of reputation data) > to determine this. The version of this that I believe is essential is a statement of the types of actions that are envisioned based on a reputation response. I'm not looking for a spec of how the output /will/ be used, but a description of what it is good for and by whom. That is, in concrete terms, what is the work of the group /for/? Who will use it and how? What can they do with it? I find the current draft text confusing on these points, and I'm also very unclear who is lining up to use the output. Absent a vigorous market pull for using the output of the wording group, the danger will be a nicely-done specification that fills what has euphemistically called a much-needed gap. I suggest some meeting time for resolving this. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Wed Jul 6 21:46:03 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90DD221F8A83 for ; Wed, 6 Jul 2011 21:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.152 X-Spam-Level: X-Spam-Status: No, score=-103.152 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Aql-QOjvp+Y for ; Wed, 6 Jul 2011 21:46:03 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id EFC8521F8801 for ; Wed, 6 Jul 2011 21:46: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; Wed, 6 Jul 2011 21:46:02 -0700 From: "Murray S. Kucherawy" To: "dcrocker@bbiw.net" , "domainrep@ietf.org" Date: Wed, 6 Jul 2011 21:46:01 -0700 Thread-Topic: [domainrep] Preliminary agenda, BoF scheduled Thread-Index: Acw8GlS5fl/EysFGR1+VohNdQ7Pf0QARjbyg Message-ID: References: <4E14C38C.8080905@dcrocker.net> In-Reply-To: <4E14C38C.8080905@dcrocker.net> 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] Preliminary agenda, BoF scheduled X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 04:46:03 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Dave CROCKER > Sent: Wednesday, July 06, 2011 1:20 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Preliminary agenda, BoF scheduled >=20 > Hi. >=20 > Mr. Monkeywrench, here... > [...] Thanks, Dave. I've updated the charter somewhat based on your feedback: http://www.blackops.org/~msk/domainrep/repute-charter.txt Further commentary is welcome of course, and we can cover it in more detail= if needed in the charter portion of the agenda at the BoF. -MSK From prvs=017078f0ad=steve.allam@trustsphere.com Thu Jul 7 21:16:48 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82411E807C for ; Thu, 7 Jul 2011 21:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gkdHJgqbF-2 for ; Thu, 7 Jul 2011 21:16:47 -0700 (PDT) Received: from st1.realmail-asp.co.uk (st1.realmail-asp.co.uk [80.249.110.240]) by ietfa.amsl.com (Postfix) with ESMTP id 22DDE11E807A for ; Thu, 7 Jul 2011 21:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=Z78QDgIybrgvUfuweDDrbIY9k7ACiYE4MRHkHsyjsAQ=; b=P4PaZ07C2bH8s3JeUfatANYRtGyfF1oYtmmGMdsM7W8wyP2yH76aNyHv4SdHMVEESsnZkk+9aHHnl9g6+ghPlSHCHefoNP2LBsAt1SOlLe/OBtm43yUTp3MjIVfxHnQD3ZGTIxOvA/gGsfGCPKTEM08Sg+uKBW0xJqd0uf+qZnc=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st1.realmail-asp.co.uk with esmtp id 1Qf2Ue-0004dG-Pa for domainrep@ietf.org; Fri, 08 Jul 2011 05:16:45 +0100 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1555469; Fri, 08 Jul 2011 12:09:44 +0800 Received: from [116.12.149.133] (account steve.allam@trustsphere.com HELO [10.100.1.131]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1555453 for domainrep@ietf.org; Fri, 08 Jul 2011 12:09:35 +0800 Message-ID: <4E1684A2.6080107@trustsphere.com> Date: Fri, 08 Jul 2011 05:16:34 +0100 From: Steve Allam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110613 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: multipart/alternative; boundary="------------030905090503080405070805" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (ignore:UNKNOWN.UNKNOWN) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0206.4E1684AD.0080,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: [domainrep] Introduction X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 04:16:48 -0000 This is a multi-part message in MIME format. --------------030905090503080405070805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This is my first email to the group - just wanted to introduce myself, although some of you already know me from maawg. I am CTO of TrustSphere, formally named BoxSentry. Murray let me know what was being planned within these standards and I was interested to see that the standards were not far away from the APIs we already used on our products: - TrustCloud; a domain+ip whitelist which uses a DNS lookup API, kinda similar to the proposals - LogiQ; an automated reputation engine which uses an HTTP API, again sort of similar. I made a few comments to Murray at maawg about possible changes to the standards that would enable us to fit within the framework. - I'm not looking for changes specific to what we are doing, but some changes that I feel are essential to support extensibility within the standard, and thus allow organisations such as ourselves to usefully use the standard. To that end, I willing to modify our existing APIs to support the standard once it is a bit more mature. Its good to see things happening in this area! Would you like me to submit my comments directly to the group, or to Murray directly? Regards, Steve -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------030905090503080405070805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

This is my first email to the group - just wanted to introduce myself, although some of you already know me from maawg.
I am CTO of TrustSphere, formally named BoxSentry.

Murray let me know what was being planned within these standards and I was interested to see that the standards were not far away from the APIs we already used on our products:

    - TrustCloud; a domain+ip whitelist which uses a DNS lookup API, kinda similar to the proposals
    - LogiQ; an automated reputation engine which uses an HTTP API, again sort of similar.

I made a few comments to Murray at maawg about possible changes to the standards that would enable us to fit within the framework. - I'm not looking for changes specific to what we are doing, but some changes that I feel are essential to support extensibility within the standard, and thus allow organisations such as ourselves to usefully use the standard.

To that end, I willing to modify our existing APIs to support the standard once it is a bit more mature.

Its good to see things happening in this area!

Would you like me to submit my comments directly to the group, or to Murray directly?

Regards,

Steve

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
steve.allam@trustsphere.com | www.trustsphere.com

--------------030905090503080405070805-- From msk@cloudmark.com Fri Jul 8 07:05:38 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082E921F87C5 for ; Fri, 8 Jul 2011 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.387 X-Spam-Level: X-Spam-Status: No, score=-103.387 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvRvP-YGG3+E for ; Fri, 8 Jul 2011 07:05:37 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 983FB21F871A for ; Fri, 8 Jul 2011 07:05:37 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 8 Jul 2011 07:05:37 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 8 Jul 2011 07:05:36 -0700 Thread-Topic: [domainrep] Introduction Thread-Index: Acw9JdxztDz6vPAIQ8KPeN6tCjPlmwAUgOmg Message-ID: References: <4E1684A2.6080107@trustsphere.com> In-Reply-To: <4E1684A2.6080107@trustsphere.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] Introduction X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 14:05:38 -0000 > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Steve Allam > Sent: Thursday, July 07, 2011 9:17 PM > To: domainrep@ietf.org > Subject: [domainrep] Introduction >=20 > Would you like me to submit my comments directly to the group, or to Murr= ay directly? Hi Steve, Posting your feedback here would be great. We might even be able to tweak = the initial draft set to include it before the BoF later this month. Thank= s for joining! -MSK From nsb@guppylake.com Sun Jul 17 03:00:42 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E1E21F872E for ; Sun, 17 Jul 2011 03:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-1.230, BAYES_20=-0.74, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fs8plcj0nBq for ; Sun, 17 Jul 2011 03:00:41 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9A21F86DE for ; Sun, 17 Jul 2011 03:00:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=g7q7uVrKi1deaiR/1hk/Vl68TDL4OQroazCxxJ/Lw0RqMt3aOOIl8rz0nuxrUR/DH+zRDjjtaeKNId+WIGJ/YcRX++qUAzZSJTLUe7yUhxCrTx/pYkeIR9dw0D6plfOX; Received: from host-39-196-68-109.spectrum1.uk.sharedband.net ([109.68.196.39] helo=[10.1.0.211]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QiO9M-0006gB-84 for domainrep@ietf.org; Sun, 17 Jul 2011 06:00:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Nathaniel Borenstein In-Reply-To: Date: Sun, 17 Jul 2011 11:00:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> To: domainrep@ietf.org X-Mailer: Apple Mail (2.1084) 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: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 10:00:42 -0000 I have a few belated comments, catching up in preparation for QC: -- The concern over meta-reputation is, I suspect, overblown. By = analogy, consider credit ratings: A few well-known entities are = generally trusted (to a point), their reputations broad enough and their = number small enough to obviate the need for an automated mechanism to = assess them. This is not to say that it wouldn't be useful to find out = if people prefer TransUnion to Experian, merely that it isn't necessary = to have a lot of infrastructure to know that they're both fairly well = respected, and that it's not a huge mistake to set up a direct = relationship with them. I've been working on the assumption that a few = fairly well-known reputation authorities will suffice to provide = reputation information about a much larger world. I agree with Murray = that it would be possible, in the current proposed framework, to set up = "a reputation vocabulary for describing reputation services" but I doubt = that it's necessary. For purposes of preventing phishing in the bank = industry, for example, it would be reasonable to simply identify and = trust a banking industry group to list the entities that are known to be = banks (citibank yes, cit1bank no). -- John makes a good point when he writes > I suspect that people would be happier with a ZIP-CODE field with a = five digit value rather than 100,000 assertions like IS-ZIP-90210.=20 My guess is that there's not much point in using reputations -- positive = OR negative -- for matters that aren't controversial, or where people = have no incentive to lie. =20 -- My first response to the issue of scaling from 0 to 1 vs -1 to 1 was = a big yawn, because they're obviously functionally equivalent, but then = I realized we're arguably talking about two different ways of thinking = about it. Peter's suggestion implies that a reputation starts at 0 and = moves up or down based on more data, while the 0-1 model is simply = envisioning a scale from bad to good; 0.5 on that scale is functionally = equivalent to 0 on Peter's scale, but doesn't as obviously carry with it = any assumptions about how much data you have. We tried to address that, = in the drafts, by giving the number of data points. I like the = explicitness of that, but it may not be as clear. If you're trying to = express a neutral reputation, 0 seems more obvious than 0.5. I look forward to seeing many of you in Quebec -- travel safely! -- = Nathaniel From prvs=0180ae9632=steve.allam@trustsphere.com Mon Jul 18 06:00:16 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C6A21F8BFF for ; Mon, 18 Jul 2011 06:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.062 X-Spam-Level: X-Spam-Status: No, score=0.062 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_COM=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0SW8LXID0rN for ; Mon, 18 Jul 2011 06:00:12 -0700 (PDT) Received: from st3.realmail-asp.co.uk (fe1.securerealmail.com [80.249.110.150]) by ietfa.amsl.com (Postfix) with ESMTP id BD7E021F8BF8 for ; Mon, 18 Jul 2011 06:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=atU7hiFdXbx1qzHguzeG+uvl68P3b4t3tMn0heO+QnI=; b=Uc/GmomF348aiIz9xzJSc7VWd9cqwlXtLL4JXCARljGY8P8Q8bh6HmrfatGnVLItdGY4SXcoWL1Y3DYHzWyNDH7Zj/Z5cnAPoU7vTZbQzUH+l0QBkxifANZNV0hnmrX8KpeifG6g98A7miv9Z/dIBiLvqqFmUEr0nOZ6ZnsLSzM=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st3.realmail-asp.co.uk with esmtp id 1QinQf-0006wS-VS for domainrep@ietf.org; Mon, 18 Jul 2011 14:00:10 +0100 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1570488; Mon, 18 Jul 2011 20:52:56 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.38]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1570491 for domainrep@ietf.org; Mon, 18 Jul 2011 20:52:41 +0800 Message-ID: <4E242E46.8040908@trustsphere.com> Date: Mon, 18 Jul 2011 13:59:50 +0100 From: Steve Allam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110613 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: multipart/alternative; boundary="------------050908070402020802060900" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (error socket failure) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B0208.4E242E5A.00D3,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: [domainrep] Possible changes to the standard. (DNS/UDP) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:00:16 -0000 This is a multi-part message in MIME format. --------------050908070402020802060900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Again, sorry for the delay - a 10 day trip to Singapore seems to knock out my todo list.. In terms of what I thought might help in the standard, at least in terms of us being able to move to it: In the DNS variant, we have a domain+ip whitelist which provides a whole host of reputation based on the 127.x.y.z. response, which perhaps goes beyond the scope of the standard to provide guidelines for how to represent the x.y.z (beyond what already exists for RWL). However, our query is of the format: ... Where: - The md5 hash is basically a hash of the concatenation of domain and IP values. - The cust key is a both a customer key and identifier, used to control access to the service - The service denotes the particular list they are accessing - The server is well, the server. So this matches the draft with the exception of the customer key, but of course you could loosely regard this as being a fit - you may not want to specify the use of a key, perhaps allow for it being there as an option? As to the md5 hash - we would be happy to switch to a different hashing scheme - I wonder whether the spec can be extended here, in case other users wanted to provide instead encrypted data (rather than hashed data) for some reason - on the one hand specifying a particular hash algorithm means that client components can be standardised - on the other hand, if the standard is too flexible, you end up describing a mechanism too loose to be called a standard at all. So all in all, to say that we adhered to the standard at the moment would require us to switch hashing schemes, and maybe denote that the . actually denotes a for the particular customer....? Regards, Steve -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------050908070402020802060900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

Again, sorry for the delay - a 10 day trip to Singapore seems to knock out my todo list..

In terms of what I thought might help in the standard, at least in terms of us being able to move to it:

In the DNS variant, we have a domain+ip whitelist which provides a whole host of reputation based on the 127.x.y.z. response, which perhaps goes beyond the scope of the standard to provide guidelines for how to represent the x.y.z (beyond what already exists for RWL). However, our query is of the format:

<md5 hash>.<cust key>.<service>.<server>
Where:
     - The md5 hash is basically a hash of the concatenation of domain and IP values.
     - The cust key is a both a customer key and identifier, used to control access to the service
     - The service denotes the particular list they are accessing
     - The server is well, the server.

So this matches the draft with the exception of the customer key, but of course you could loosely regard this as being a fit - you may not want to specify the use of a key, perhaps allow for it being there as an option?

As to the md5 hash - we would be happy to switch to a different hashing scheme - I wonder whether the spec can be extended here, in case other users wanted to provide instead encrypted data (rather than hashed data) for some reason - on the one hand specifying a particular hash algorithm means that client components can be standardised - on the other hand, if the standard is too flexible, you end up describing a mechanism too loose to be called a standard at all.

So all in all, to say that we adhered to the standard at the moment would require us to switch hashing schemes, and maybe denote that the <cust key>.<service> actually denotes a <service> for the particular customer....?

Regards,

Steve

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
steve.allam@trustsphere.com | www.trustsphere.com
--------------050908070402020802060900-- From prvs=0180ae9632=steve.allam@trustsphere.com Mon Jul 18 06:21:47 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12B7521F8BB8 for ; Mon, 18 Jul 2011 06:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_17=0.6, J_CHICKENPOX_18=0.6, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3HxbZ8aPlUA for ; Mon, 18 Jul 2011 06:21:42 -0700 (PDT) Received: from st1.realmail-asp.co.uk (st1.realmail-asp.co.uk [80.249.110.240]) by ietfa.amsl.com (Postfix) with ESMTP id B5B0921F8B9B for ; Mon, 18 Jul 2011 06:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=trustsphere.com; s=rmdkim; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=QtFjScTlJzRZskn5y+x+VEM7iMLadHT1oIWOlqQJuj4=; b=Mj2GNyHmbMVfdwlbHe6rT2O+nNYHYfa5Xo66JltkYDxxrzp6X9OYmbRSUe2vvm1sd/itbwvsATitdgyfM7O6E0Kw/WFSQQMpKXmkR+tGA9GCrcvB+Rv0eIuR14o6XGayrhdGF5a/sON0R4pil3MMu28250D+MVgEvigO9JZJ4f4=; Received: from [116.12.149.130] (helo=cgpro.boxsentry.com) by st1.realmail-asp.co.uk with esmtp id 1QinlT-0002Ip-Pl for domainrep@ietf.org; Mon, 18 Jul 2011 14:21:40 +0100 Received: by cgpro.boxsentry.com (CommuniGate Pro PIPE 5.4.0) with PIPE id 1570499; Mon, 18 Jul 2011 21:14:26 +0800 Received: from [88.97.130.81] (account steve.allam@trustsphere.com HELO [10.1.1.38]) by cgpro.boxsentry.com (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 1570485 for domainrep@ietf.org; Mon, 18 Jul 2011 21:14:23 +0800 Message-ID: <4E24335A.9000203@trustsphere.com> Date: Mon, 18 Jul 2011 14:21:30 +0100 From: Steve Allam User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110613 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: multipart/alternative; boundary="------------030709050203070005070702" X-RMR-rmalert: true X-LogiQ-query: 116.12.149.130/steve.allam@trustsphere.com/domainrep@ietf.org (ignore:UNKNOWN.EXISTS) X-RealMail-Category: UNKNOWN/UNKNOWN X-RealMail-Ref: UNKNOWN/str=0001.0A0B020B.4E243364.01CC,ss=1,re=0.000,fgs=0 X-RealMail-IWF: NO X-CTCH-SenderID: steve.allam@trustsphere.com X-CTCH-SenderID-Flags: 0 X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-Total-Spam: 0 X-CTCH-SenderID-Total-Suspected: 0 Subject: [domainrep] Possible changes to the standard (HTTP) X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2011 13:21:47 -0000 This is a multi-part message in MIME format. --------------030709050203070005070702 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit All, The other interface we use to connect to our 'reputation engine' (the LogiQ product) uses an HTTP GET query. A typical query would be: http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&d=inbound and this can be extended using a variety of other parameters such as: http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&spf=pass&dkim=pass&v=spam&subject=test_message&d=inbound If we try and encode that in the current proposed standard, we can get as far as perhaps: http://logiq.server.com:8000/email/here.com/sender-rep But then need to define the sender and other parameters. This is my main comment - there needs to be a mechanism for people to add extensible parameters to the basic query. When we decided on the query were were going to use, we took a number of factors into consideration: 1. Where will the url parsing take place? - we decided to keep the url fixed for all queries, and pass the variable data in via parameters. Mainly this was due to having many parameters to parse, and keeping the http engine for what it was good at, passing all the parameters to the application to handle. We do however do some work in the HTTP server (nginx) based on the params - for instance, depending on whether we get d=inbound or d=outbound, we set different rate limiting values. However, the basic premise was - keep the application separate from the web server - although clearly an application is quite capable of parsing a URL as well as a param stream. 2. Do we use a GET or a POST to provide params? - we decided that as we weren't sending extended parameter data, we could live without the extra overhead of a POST command - one of the purposes of our engine is to work as fast as possible after all. - parameter names were again simply made as small as possible to ensure the query fitted into as few packets as possible - a little thing perhaps.... 3. Responses.... - LogiQ is capable of returning responses in three formats: - XML: we wanted to use this as it is nicely extensible. In practice, not many of our interfaces use it; partly because when people start using it they load up an XML parser and process the result....whoops...that's gone slow for some reason.... - Text: As the response line is usually a single line, its simple..... - HTTP response code - this is the fastest and used directly in out interface with the Cloudmark Gateway - as it can support direct HTTP get queries in its rules the LogiQ interface needs no extra modules. In order to get the quickest integration, the gateway merely uses the response code to determine reputation, and can drill down into the response body if more information is needed. I don't expect this to be considered for a standard however. I can't remember the exact responses we use but its something like 201 for good reputation, 404 for unknown and 503 for a bad reputation. I know perhaps I have rambled a bit here - but I hope it gives an idea of how we are using similar mechanisms for reputation query/response - please let me know if you have any questions. Regards, Steve -- * Steve Allam | * Chief Technology Officer *| TrustSphere * 3 Phillip Street, #13-03 Commerce Point, Singapore, 048693 Tel: +65 6536 5203 | Fax: +65 6536 5463 steve.allam@trustsphere.com | www.trustsphere.com --------------030709050203070005070702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit All,

The other interface we use to connect to our 'reputation engine' (the LogiQ product) uses an HTTP GET query. A typical query would be:

http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&d=inbound

and this can be extended using a variety of other parameters such as:

http://logiq.server.com:8000/check_sender?i=193.4.5.2&s=murray@there.com&r=steve@here.com&spf=pass&dkim=pass&v=spam&subject=test_message&d=inbound

If we try and encode that in the current proposed standard, we can get as far as perhaps:

http://logiq.server.com:8000/email/here.com/sender-rep

But then need to define the sender and other parameters. This is my main comment - there needs to be a mechanism for people to add extensible parameters to the basic query.

When we decided on the query were were going to use, we took a number of factors into consideration:

1. Where will the url parsing take place?
    - we decided to keep the url fixed for all queries, and pass the variable data in via parameters. Mainly this was due to having many parameters to parse, and keeping the http engine for what it was good at, passing all the parameters to the application to handle. We do however do some work in the HTTP server (nginx) based on the params - for instance, depending on whether we get d=inbound or d=outbound, we set different rate limiting values. However, the basic premise was - keep the application separate from the web server - although clearly an application is quite capable of parsing a URL as well as a param stream.

2. Do we use a GET or a POST to provide params?
    - we decided that as we weren't sending extended parameter data, we could live without the extra overhead of a POST command - one of the purposes of our engine is to work as fast as possible after all.
    - parameter names were again simply made as small as possible to ensure the query fitted into as few packets as possible - a little thing perhaps....

3. Responses....
    - LogiQ is capable of returning responses in three formats:
        - XML: we wanted to use this as it is nicely extensible. In practice, not many of our interfaces use it; partly because when people start using it they load up an XML parser and process the result....whoops...that's gone slow for some reason....
        - Text:   As the response line is usually a single line, its simple.....
        - HTTP response code - this is the fastest and used directly in out interface with the Cloudmark Gateway - as it can support direct HTTP get queries in its rules the LogiQ interface needs no extra modules. In order to get the quickest integration, the gateway merely uses the response code to determine reputation, and can drill down into the response body if more information is needed. I don't expect this to be considered for a standard however. I can't remember the exact responses we use but its something like 201 for good reputation, 404 for unknown and 503 for a bad reputation.

I know perhaps I have rambled a bit here - but I hope it gives an idea of how we are using similar mechanisms for reputation query/response - please let me know if you have any questions.

Regards,

Steve

--

Steve Allam | Chief Technology Officer | TrustSphere

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
steve.allam@trustsphere.com | www.trustsphere.com
--------------030709050203070005070702-- From vesely@tana.it Wed Jul 20 04:06:47 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4821F8A66 for ; Wed, 20 Jul 2011 04:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.83 X-Spam-Level: X-Spam-Status: No, score=-4.83 tagged_above=-999 required=5 tests=[AWL=-0.111, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NANnJ7Qaviiz for ; Wed, 20 Jul 2011 04:06:43 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4C50421F8A62 for ; Wed, 20 Jul 2011 04:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311159997; bh=koNepXXHhWQDcUTLresxWrfCjjHCzOPrCBCIq8xl+dE=; l=825; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=hmbob3p4mnD9O+rFIuSu5o3tzo5X8NIcOf4SrM85I4sAdMteAO0QbdmtNmYN/AMMM e3tPhdm+9HXSBGEouuT02iNnPze9yTIUT2Aw8O7ppeI+5AB3D0ujqC7A25+/Zts5Ap O4OK16pxMc6mjTHgoP7K1G6AJa6TGpJpP9GVX7Js= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Wed, 20 Jul 2011 13:06:37 +0200 id 00000000005DC035.000000004E26B6BD.0000529D Message-ID: <4E26B6BD.10104@tana.it> Date: Wed, 20 Jul 2011 13:06:37 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> In-Reply-To: <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 11:06:47 -0000 On 17/Jul/11 12:00, Nathaniel Borenstein wrote: > -- My first response to the issue of scaling from 0 to 1 vs -1 to 1 > was a big yawn, because they're obviously functionally equivalent, > but then I realized we're arguably talking about two different ways > of thinking about it. Peter's suggestion implies that a reputation > starts at 0 and moves up or down based on more data While they may seem functionally equivalent at a purely numerical glance, they are not. The point with negative ranges is that they are used as synonym for blacklisting. A domain-based reputation system cannot be used as an effective blacklist: Otherwise, spammers can use it as an adviser for changing domain names at the right time. Hence the blacklist won't block them, although we hypothesized it is effective. Contradiction. From msk@cloudmark.com Wed Jul 20 10:31:35 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4AB21F8640 for ; Wed, 20 Jul 2011 10:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.881 X-Spam-Level: X-Spam-Status: No, score=-103.881 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzjXHkUKkxeK for ; Wed, 20 Jul 2011 10:31:34 -0700 (PDT) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.35]) by ietfa.amsl.com (Postfix) with ESMTP id ACAB921F863E for ; Wed, 20 Jul 2011 10:31: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; Wed, 20 Jul 2011 10:31:34 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "domainrep@ietf.org" Date: Wed, 20 Jul 2011 10:31:32 -0700 Thread-Topic: [domainrep] At long last, some drafts and a charter Thread-Index: AcxGzSAPKa+aCtC2SomiFmJdnj/yHQANRqcg Message-ID: References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> In-Reply-To: <4E26B6BD.10104@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] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:31:35 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Alessandro Vesely > Sent: Wednesday, July 20, 2011 4:07 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] At long last, some drafts and a charter >=20 > While they may seem functionally equivalent at a purely numerical > glance, they are not. The point with negative ranges is that they are > used as synonym for blacklisting. A domain-based reputation system > cannot be used as an effective blacklist: Otherwise, spammers can use > it as an adviser for changing domain names at the right time. Hence > the blacklist won't block them, although we hypothesized it is > effective. Contradiction. This seems like a blanket statement to me. What a negative value means rea= lly depends on with what assertion it is being associated. I suspect if consensus is to allow [-1, 1] as the range, then the declarati= on of a new assertion will need to explain how a consumer is expected to ap= ply a negative value or, indeed, if they are allowed at all for that assert= ion. For example, I suggest that in general we say a value of 1 agrees str= ongly with the assertion being made, 0 disagrees with it, and -1 disagrees = and asserts the opposite. SENDS-HIGH-VOLUME might be one for which negative numbers make sense, where= values tending towards 1 mean "yes, this sender sends a huge amount of mai= l", 0 means "this sender sends an average amount of mail", and -1 means "no= , this sender actually sends very little mail". On the other hand, an assertion of SENDS-VIRUSES is one where I can't imagi= ne what a negative assertion might mean (i.e., what's the opposite?). From stpeter@stpeter.im Wed Jul 20 10:41:08 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6D321F84E5 for ; Wed, 20 Jul 2011 10:41:08 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQJsZZ4u93hw for ; Wed, 20 Jul 2011 10:41:03 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D567921F87AF for ; Wed, 20 Jul 2011 10:41:03 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5B29B4005A; Wed, 20 Jul 2011 11:41:45 -0600 (MDT) Message-ID: <4E27132D.5070209@stpeter.im> Date: Wed, 20 Jul 2011 11:41:01 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "domainrep@ietf.org" , Alessandro Vesely Subject: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 17:41:08 -0000 On 7/20/11 11:31 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Alessandro Vesely >> Sent: Wednesday, July 20, 2011 4:07 AM >> To: domainrep@ietf.org >> Subject: Re: [domainrep] At long last, some drafts and a charter >> >> While they may seem functionally equivalent at a purely numerical >> glance, they are not. The point with negative ranges is that they are >> used as synonym for blacklisting. A domain-based reputation system >> cannot be used as an effective blacklist: Otherwise, spammers can use >> it as an adviser for changing domain names at the right time. Hence >> the blacklist won't block them, although we hypothesized it is >> effective. Contradiction. > > This seems like a blanket statement to me. What a negative value means really depends on with what assertion it is being associated. > > I suspect if consensus is to allow [-1, 1] as the range, then the declaration of a new assertion will need to explain how a consumer is expected to apply a negative value or, indeed, if they are allowed at all for that assertion. For example, I suggest that in general we say a value of 1 agrees strongly with the assertion being made, 0 disagrees with it, and -1 disagrees and asserts the opposite. > > SENDS-HIGH-VOLUME might be one for which negative numbers make sense, where values tending towards 1 mean "yes, this sender sends a huge amount of mail", 0 means "this sender sends an average amount of mail", and -1 means "no, this sender actually sends very little mail". > > On the other hand, an assertion of SENDS-VIRUSES is one where I can't imagine what a negative assertion might mean (i.e., what's the opposite?). Who defines the assertions? How do we avoid overlap and confusion between assertions? For, say, an SMTP or XMPP server I could see assertions like this: - SUPPORTS TLS USING A PKIK CERTIFICATE - HAS A CA-ISSUED CERT - HAS A SELF-SIGNED CERT - HAS AN EXPIRED CERT It's not clear how to usefully interpret the results if all of those assertions are in play. :) It also seems that in some systems people might think they can aggregate scores on particular dimensions into general scores. That might be a challenge if the measurements are overlapping or not commensurate. To feel free to tell me this is already defined in a document I haven't had time to read yet... Peter -- Peter Saint-Andre https://stpeter.im/ From nsb@guppylake.com Thu Jul 21 01:05:12 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF1D21F8B56 for ; Thu, 21 Jul 2011 01:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NmLPtrrikSZ for ; Thu, 21 Jul 2011 01:05:08 -0700 (PDT) Received: from server1.netnutz.com (server1.netnutz.com [72.233.90.3]) by ietfa.amsl.com (Postfix) with ESMTP id 344A221F8B51 for ; Thu, 21 Jul 2011 01:05:08 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=guppylake.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=co7R7TWuU2rOEJRZ2NFX1scAFP4wTqa7qdzQzq/dlobUJ7Mgq2HCKl8jvkQt0/tBXBRjPFgXctO2QxmZ7kFldvC5fUlpMvc5WjSZmPpbPlYt1AYXn2OB8uTAbsAK5Klb; Received: from host-39-196-68-109.spectrum1.uk.sharedband.net ([109.68.196.39] helo=[10.1.0.227]) by server1.netnutz.com with esmtpa (Exim 4.69) (envelope-from ) id 1QjoFU-0006p9-AM; Thu, 21 Jul 2011 04:04:50 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Nathaniel Borenstein In-Reply-To: <4E27132D.5070209@stpeter.im> Date: Thu, 21 Jul 2011 09:04:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1084) 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" , Alessandro Vesely Subject: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 08:05:12 -0000 On 7/20/11 11:31 AM, Murray S. Kucherawy wrote: > On the other hand, an assertion of SENDS-VIRUSES is one where I can't = imagine what a negative assertion might mean (i.e., what's the = opposite?). I think the idea is that 1 would mean definitely yes, -1 would mean = definitely no (doesn't send viruses), and 0 would mean the rater has no = clue, while 0.5 would mean the rater has seen some evidence of sending = viruses but it's not overwhelming. (Sending one virus can easily be an = accident, ask your clueless users.) While I still think it's (obviously) mathematically equivalent to a = [0,1] scale, the [-1,1] scale may actually be more comprehensible. But = it feels like the kind of thing that's so fundamentally minor that we = will end up fighting over it tooth and nail. :-( On Jul 20, 2011, at 6:41 PM, Peter Saint-Andre wrote: > Who defines the assertions? How do we avoid overlap and confusion = between assertions? The assertions are defined as part of the vocabularly, which is defined = for each application/instantiation of the protocol. So in your = examples, you'd be getting the assertions from an SMTP vocabulary, an = XMPP vocabulary, etc. -- Nathaniel From vesely@tana.it Fri Jul 22 01:04:02 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C41B21F86A2 for ; Fri, 22 Jul 2011 01:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.816 X-Spam-Level: X-Spam-Status: No, score=-4.816 tagged_above=-999 required=5 tests=[AWL=-0.097, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dtv0qZ8Ga3DV for ; Fri, 22 Jul 2011 01:04:01 -0700 (PDT) Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5258621F8591 for ; Fri, 22 Jul 2011 01:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311321818; bh=gfHWzx7vGGTfsea198d31QFc9rohB+Ma9h1wEqcPnM8=; l=1261; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=Dz6kPggzwaZuK7Onnk6PJ2MA2qfgb3GECivroLzNWL6xrsfcUmqkUQq8fVeR2D41E caz17nokPNxCvoKV4e0nGajFBbEar6fBq12Od0ObXupP7aApOCzo4QxokMaX+sIzB2 Ucv6ROr6gFQGuaNIdso5oNRQ0nH/EYm0Kdz3GxVY= 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, 22 Jul 2011 10:03:38 +0200 id 00000000005DC045.000000004E292EDA.0000646F Message-ID: <4E292EDA.6010105@tana.it> Date: Fri, 22 Jul 2011 10:03:38 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 08:04:02 -0000 On 21/Jul/11 10:04, Nathaniel Borenstein wrote: > I think the idea is that 1 would mean definitely yes, -1 would mean > definitely no (doesn't send viruses), and 0 would mean the rater > has no clue, while 0.5 would mean the rater has seen some evidence > of sending viruses but it's not overwhelming. (Sending one virus > can easily be an accident, ask your clueless users.) Oh well, I'm sorry for my "blanket statement", I thought we were talking about executive results. > While I still think it's (obviously) mathematically equivalent to a > [0,1] scale, the [-1,1] scale may actually be more comprehensible. > But it feels like the kind of thing that's so fundamentally minor > that we will end up fighting over it tooth and nail. :-( For basic assertions, I don't think scaling makes much sense. For example, one can scale the ESTIMATED-USERS by 7G so as to obtain a probability in the [0, 1] range, but such practice alters the nature of the original statement somewhat. Another example is dates, useful to express qualities such as REGISTERED-ON, FIRST-HAM-EVER-SENT. It may be preferable to have a few homogeneous types, identified by ranges --not necessarily numeric--, and leave any scaling to the "secret sauce" recipes. From msk@cloudmark.com Fri Jul 22 01:26:38 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D95821F85B9 for ; Fri, 22 Jul 2011 01:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYookJGIRTZK for ; Fri, 22 Jul 2011 01:26:37 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id A9D8921F8550 for ; Fri, 22 Jul 2011 01:26:37 -0700 (PDT) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 22 Jul 2011 01:26:37 -0700 From: "Murray S. Kucherawy" To: Alessandro Vesely , "domainrep@ietf.org" Date: Fri, 22 Jul 2011 01:26:36 -0700 Thread-Topic: [domainrep] At long last, some drafts and a charter Thread-Index: AcxIRfI/b8V52Ao2QuOZYjKdaYbWXwAAu0ig Message-ID: References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> <4E292EDA.6010105@tana.it> In-Reply-To: <4E292EDA.6010105@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] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 08:26:38 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Alessandro Vesely > Sent: Friday, July 22, 2011 1:04 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] At long last, some drafts and a charter >=20 > For basic assertions, I don't think scaling makes much sense. For > example, one can scale the ESTIMATED-USERS by 7G so as to obtain a > probability in the [0, 1] range, but such practice alters the nature > of the original statement somewhat. Another example is dates, useful > to express qualities such as REGISTERED-ON, FIRST-HAM-EVER-SENT. I don't think those are qualities that lend themselves to metrics of reputa= tion. Those are absolutes, rather than expressions of opinion about an ent= ity. The former would be something I'd expect to get out of WHOIS, for example. From vesely@tana.it Fri Jul 22 03:26:44 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5AC21F867F for ; Fri, 22 Jul 2011 03:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.812 X-Spam-Level: X-Spam-Status: No, score=-4.812 tagged_above=-999 required=5 tests=[AWL=-0.092, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QsafVjrrnyL for ; Fri, 22 Jul 2011 03:26:43 -0700 (PDT) Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5824F21F8681 for ; Fri, 22 Jul 2011 03:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1311330400; bh=0wT5eQFIfYDTOCLsAAC2kH8nRQVbazPsfgBvlFUmZm4=; l=1028; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=MhNmm46dfQw/+uZWadgs6uFTU2FWa67i4gHlA3YiQY1bZv7ZhCkF1SMB11M1FSzJB F4ddIYESyOT8zsC/JW2RH95akL+eYQI37QmxNJ1SH4npLMsJgWtpO6dqWa60ku6ED7 n6ZDaW4CQCHeHqXZjEc3F08kSMY+2vL8/vefIr2c= 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, 22 Jul 2011 12:26:40 +0200 id 00000000005DC039.000000004E295060.00000BC0 Message-ID: <4E295060.2040608@tana.it> Date: Fri, 22 Jul 2011 12:26:40 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: domainrep@ietf.org References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> <4E292EDA.6010105@tana.it> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 10:26:44 -0000 On 22/Jul/11 10:26, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: domainrep On Behalf Of Alessandro Vesely >> >> For basic assertions, I don't think scaling makes much sense. For >> example, one can scale the ESTIMATED-USERS by 7G so as to obtain a >> probability in the [0, 1] range, but such practice alters the nature >> of the original statement somewhat. Another example is dates, useful >> to express qualities such as REGISTERED-ON, FIRST-HAM-EVER-SENT. > > I don't think those are qualities that lend themselves to metrics of reputation. How do you define "metrics of reputation"? > Those are absolutes, rather than expressions of opinion about an entity. > > The former would be something I'd expect to get out of WHOIS, for example. Yes, there's some overlapping. It is not clear to what extent WHOIS information is going to be complemented and not rate limited. The existence of an abuse mailbox and, possibly, the number of complaints sent to it may also be interesting. From msk@cloudmark.com Fri Jul 22 07:05:11 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2A21F877D for ; Fri, 22 Jul 2011 07:05:11 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc+mACukuZnw for ; Fri, 22 Jul 2011 07:05:11 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id CDF7021F8793 for ; Fri, 22 Jul 2011 07:04: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; Fri, 22 Jul 2011 07:04:53 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 22 Jul 2011 07:04:52 -0700 Thread-Topic: [domainrep] At long last, some drafts and a charter Thread-Index: AcxIWdunQZHWAYG1RkCO493l0ecvhgAHaf9Q Message-ID: References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> <4E292EDA.6010105@tana.it> <4E295060.2040608@tana.it> In-Reply-To: <4E295060.2040608@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] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:05:11 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of Alessandro Vesely > Sent: Friday, July 22, 2011 3:27 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] At long last, some drafts and a charter >=20 > >> For basic assertions, I don't think scaling makes much sense. For > >> example, one can scale the ESTIMATED-USERS by 7G so as to obtain a > >> probability in the [0, 1] range, but such practice alters the nature > >> of the original statement somewhat. Another example is dates, useful > >> to express qualities such as REGISTERED-ON, FIRST-HAM-EVER-SENT. > > > > I don't think those are qualities that lend themselves to metrics of > > reputation. >=20 > How do you define "metrics of reputation"? The dictionary defines reputation as "the estimation in which a person or t= hing is held, especially by the community or the public generally". It thu= s seems to me that your two suggested qualities might be things one uses in= computing a reputation, but are not themselves reputations. You might use a domain registration date as part of the overall data set yo= u use to assert a SUSPECT reputation, for example, where that value tends t= owards 1 as the registration date is more recent. From dfs@roaringpenguin.com Fri Jul 22 07:11:12 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA0C21F8879 for ; Fri, 22 Jul 2011 07:11:12 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gq+9hlYzMfwH for ; Fri, 22 Jul 2011 07:11:11 -0700 (PDT) Received: from colo3.roaringpenguin.com (www.ipv6.roaringpenguin.com [IPv6:2607:f748:1200:fb:70:38:112:54]) by ietfa.amsl.com (Postfix) with ESMTP id B2D8021F86DF for ; Fri, 22 Jul 2011 07:11:10 -0700 (PDT) Received: from vanadium.roaringpenguin.com (vanadium.roaringpenguin.com [192.168.10.23]) by colo3.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6MEB9hb007160 for ; Fri, 22 Jul 2011 10:11:09 -0400 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p6MEB7Vb000421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 22 Jul 2011 10:11:08 -0400 Date: Fri, 22 Jul 2011 10:11:06 -0400 From: "David F. Skoll" To: "domainrep@ietf.org" Message-ID: <20110722101106.2ba60a97@hydrogen.roaringpenguin.com> In-Reply-To: References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> <4E292EDA.6010105@tana.it> <4E295060.2040608@tana.it> Organization: Roaring Penguin Software Inc. X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=roaringpenguin.com; h=date :from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; s=beta; bh=TX6PL9pRnkwc OEsS5UNBo+S2GaQ=; b=tH1hQJ3hXXlWon0wcl8qzIAIRUlouamPnf+L0Lvma897 Qh7HiD1NGcRGE8q9as6NYMuZvL3ALnrjX1Fsiq2gqvGoORL9TBPcZrM7xQMOFxvi XRy7XVcP+T34iXN8QndpSazCySWvHb7O+tam5tv2eM/MzADQrhGCMZYGp6sVPxY= X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.7.18 X-Scanned-By: MIMEDefang 2.72 on 192.168.10.23 X-CanIt-Geo: No geolocation information available for 192.168.10.23 X-CanItPRO-Stream: outgoing (inherits from default) X-CanIt-Archive-Cluster: SQVyZJxqklY5buiWXYCN4T/BjiM X-CanIt-Archived-As: base/20110722 / 01Fb2b9Rm Subject: Re: [domainrep] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:11:12 -0000 On Fri, 22 Jul 2011 07:04:52 -0700 "Murray S. Kucherawy" wrote: > The dictionary defines reputation as "the estimation in which a > person or thing is held, especially by the community or the public > generally". It thus seems to me that your two suggested qualities > might be things one uses in computing a reputation, but are not > themselves reputations. Well, of course. The only things you should collect about a system are objective facts. In the email realm, it is objectively true that machine 10.1.2.3 tried to send a message to a nonexistent recipient, or that machine 10.2.3.4 send an email that was classified as spam by a human. The subjectivity comes when you combine knowledge of facts to form an opinion about the system. I don't believe your charter gives any guidance about how to do this (and it probably shouldn't.) Regards, David. From msk@cloudmark.com Fri Jul 22 07:26:36 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77DD21F8879 for ; Fri, 22 Jul 2011 07:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.345 X-Spam-Level: X-Spam-Status: No, score=-103.345 tagged_above=-999 required=5 tests=[AWL=-0.746, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dzATWxmkVN14 for ; Fri, 22 Jul 2011 07:26:34 -0700 (PDT) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id E23A021F867A for ; Fri, 22 Jul 2011 07:26: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; Fri, 22 Jul 2011 07:26:34 -0700 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 22 Jul 2011 07:26:33 -0700 Thread-Topic: [domainrep] At long last, some drafts and a charter Thread-Index: AcxIeVkDGjF2l7dCR3G08C2tZf1iNwAAeNAw Message-ID: References: <4DE7D36B.7070506@tana.it> <4DE8C44F.3060504@tana.it> <4DE9573C.5050806@sonnection.nl> <007EB367-7797-453C-973B-C4FBC0C094B5@guppylake.com> <4E26B6BD.10104@tana.it> <4E27132D.5070209@stpeter.im> <4E292EDA.6010105@tana.it> <4E295060.2040608@tana.it> <20110722101106.2ba60a97@hydrogen.roaringpenguin.com> In-Reply-To: <20110722101106.2ba60a97@hydrogen.roaringpenguin.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] At long last, some drafts and a charter X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2011 14:26:36 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Friday, July 22, 2011 7:11 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] At long last, some drafts and a charter >=20 > The subjectivity comes when you combine knowledge of facts to form an > opinion about the system. I don't believe your charter gives any > guidance about how to do this (and it probably shouldn't.) I agree, although defining "reputation" by citing the dictionary might actu= ally be helpful in framing the work and providing guidance about assertions= that are reasonable to pursue. From ajs@anvilwalrusden.com Mon Jul 25 09:12:05 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3B711E8138 for ; Mon, 25 Jul 2011 09:12:05 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mkTMoAk3vBbe for ; Mon, 25 Jul 2011 09:12:04 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 9A54621F84AE for ; Mon, 25 Jul 2011 07:46:23 -0700 (PDT) Received: from shinkuro.com (dhcp-678b.meeting.ietf.org [130.129.103.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id A86A71ECB41D for ; Mon, 25 Jul 2011 14:46:22 +0000 (UTC) Date: Mon, 25 Jul 2011 10:46:16 -0400 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20110725144616.GA1579@shinkuro.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Subject: [domainrep] A sentence that confuses me X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2011 16:12:05 -0000 In draft-kucherawy-reputation-query-dns-00, we have this: In line with [DNS-EXPAND], the TXT resource record type is used for this application. But RFC 5507 says this: We'll show how such a designer almost inevitably hits upon the idea of just using a TXT Resource Record, why this is a bad thing, and why a new Resource Record Type should be allocated instead. How can these statements be reconciled? -- Andrew Sullivan ajs@anvilwalrusden.com From barryleiba.mailing.lists@gmail.com Thu Jul 28 20:20:52 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667F321F86DC for ; Thu, 28 Jul 2011 20:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.056 X-Spam-Level: X-Spam-Status: No, score=-103.056 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCpSebcwcul5 for ; Thu, 28 Jul 2011 20:20:51 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id C3D9821F86D7 for ; Thu, 28 Jul 2011 20:20:51 -0700 (PDT) Received: by yxp4 with SMTP id 4so2532356yxp.31 for ; Thu, 28 Jul 2011 20:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=JsB2O0JDbIBk3xgW3q83C/icSMUSxOd42CXAlmWXqa8=; b=V060L/ZimhLZ9EUZ/2VpdyZYHOqYovY2w6Jr7S9Ne2UBi1JeqYLxir5ghmJD0QiHjO IYpp0M0kNKJ8WtTGHwKSwKGNIhSZMSaKZi76+mhcP58YlQrJVE3Dhd0qWsz/9V0ON7SC UpSZJJm29J3BipLHYsQAQ8RJr+oLTjmAKq6Fk= MIME-Version: 1.0 Received: by 10.146.105.16 with SMTP id d16mr514711yac.13.1311909648936; Thu, 28 Jul 2011 20:20:48 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.147.32.15 with HTTP; Thu, 28 Jul 2011 20:20:48 -0700 (PDT) Date: Thu, 28 Jul 2011 23:20:48 -0400 X-Google-Sender-Auth: tR1U44ZoWyGyc382epho_0zru8Y Message-ID: From: Barry Leiba To: "domainrep@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Subject: [domainrep] Minutes from the BoF posted X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 03:20:52 -0000 I've just posted minutes from the IETF 81 BoF session, here: http://www.ietf.org/proceedings/81/minutes/repute.txt I made these unusually detailed for the discussion part, because I wanted them to capture as much of the discussion as was reasonable. Still, the recorded audio is the best place to go to hear what happened, and that is here, for now: http://www.ietf.org/audio/ietf81/ietf81-2103-20110725-1256-pm.mp3 Start listening two hours and ten minutes or so into the recording. At some point, the Secretariat will be splitting the audio files, so that our session will be in its own file. Barry, BoF chair From peer2peer@gmail.com Fri Jul 29 15:24:24 2011 Return-Path: X-Original-To: domainrep@ietfa.amsl.com Delivered-To: domainrep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3D211E80C6 for ; Fri, 29 Jul 2011 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.028 X-Spam-Level: X-Spam-Status: No, score=-3.028 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ala-J0eO5bGN for ; Fri, 29 Jul 2011 15:24:23 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2660711E8095 for ; Fri, 29 Jul 2011 15:24:23 -0700 (PDT) Received: by gyd5 with SMTP id 5so3387603gyd.31 for ; Fri, 29 Jul 2011 15:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=tJGRp2mnoTzestxEuPFv8/3rw7y4X7keJCpc3BGK+rY=; b=kT5GM5IBVa5IBQql4tMvSFzLl502s6k9/MNsCSpN4wJJccMbqxDRgKRfo217vIWA5f FzX8OVb4lQSLikjFAnpyGCUV4X9j8pAmhGyz+/zsfZ68LnlccwgzB/YG+AniOdkOIt4f PLN6rQGQrf8ZZ4i9XITBTZe9cK7SNA3fSDUjc= MIME-Version: 1.0 Received: by 10.143.97.37 with SMTP id z37mr1069354wfl.210.1311978262031; Fri, 29 Jul 2011 15:24:22 -0700 (PDT) Received: by 10.142.80.16 with HTTP; Fri, 29 Jul 2011 15:24:21 -0700 (PDT) Date: Sat, 30 Jul 2011 00:24:21 +0200 Message-ID: From: Johan Pouwelse To: domainrep@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [domainrep] Drafting a new use-case: information dissemination ? X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jul 2011 22:24:25 -0000 Dear All, At the 81th IETF BoF I've volunteered to contribute to the hopefully soon-to-be WG REPUTE. Hopefully this mailinglist can provide me with some feedback on the braindump below. Is it useful to expand this? My research team has running code, used by a few thousand people related to this use case. At some point we would love to contribute this (provided the WG+charter is ready for this). This email can hopefully combined with others in a "Survey of Proposed Use Cases for REPUTE". Proposed use case: information dissemination We define information dissemination broadly as: "the act of forwarding, relaying, caching and broadcasting packets of data towards others". We use the label "information dissemination" in a very general way deliberately. This enables us to create a common framework for four use case instances, each of which are used by millions of Internet users. Disseminating information requires several type of resources such as storage, networking and computation. Problem outline: this REPUTE use case enables participants to spent their valuable resources only on those people which are most likely not "bad actors". This promotes good behaviour, enhances performance and provides increased social welfare in general. This use case is focussed on collaborative and self-organising systems where the users share resources freely. We target the following four use case instances: 1) open wifi base station - exchanging information between the wireless and wired domain. 2) Packet forwarding - Relaying packets in an Mobile Ad-hoc Network (MANET) 3) Caching proxy - Relaxing information for others in order to enhance performance and privacy on the wired Internet 4) file sharing - pooling storage capacity together in order to build a vast archive of content Commonality between the four instances is that without REPUTE there is no mechanism to make an assessment of the trustworthiness of others. Every participant in the above use case instances MUST use REPUTE to determine if it should honour the request for resource usage. We define the reputation of an identifier or "value" in this use case: the reputation score reflects to which extend this identity has engaged in a cooperative manner in the information dissemination ecosystem. Therefore, only participants with a sufficient REPUTE value will see their information dissemination requests fulfilled. Leechers get degraded performance, get delayed before service or will not obtain any service. REFS Our work in the area of a fully self-organising reputation system for file sharing: "Improving Accuracy and Coverage in an Internet-Deployed Reputation Mechanism" http://dx.doi.org/10.1109/P2P.2010.5569965 Detailed analysis of 25 proposed reputation systems (my claim is that many of these designs are flawed) http://projects.cerias.purdue.edu/ds2/papers/reputation_survey.pdf Again, looking forward to your responses... Greetings, Johan Pouwelse