From msk@cloudmark.com Fri Dec 2 15:43: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 7BB151F0C5A for ; Fri, 2 Dec 2011 15:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.703 X-Spam-Level: X-Spam-Status: No, score=-102.703 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBVfKxz21nFb for ; Fri, 2 Dec 2011 15:43:02 -0800 (PST) Received: from ht2-outbound.cloudmark.com (ht2-outbound.cloudmark.com [72.5.239.36]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0991F0C4F for ; Fri, 2 Dec 2011 15:43:02 -0800 (PST) Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Fri, 2 Dec 2011 15:43:01 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 2 Dec 2011 15:43:00 -0800 Thread-Topic: Phishing and domain reputation Thread-Index: Acykcv4KVfHIjnElSjKwazuj54+mKAM2RsAQ Message-ID: 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: [domainrep] FW: Phishing and domain reputation 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, 02 Dec 2011 23:43:03 -0000 Of possible interest to people here... -----Original Message----- From: asrg-bounces@irtf.org [mailto:asrg-bounces@irtf.org] On Behalf Of Mar= tijn Grooten Sent: Wednesday, November 16, 2011 7:18 AM To: Anti-Spam Research Group - IRTF Subject: [Asrg] Phishing and domain reputation The anti-phishing working group (APWG) published a report on phishing in th= e first half of 2011: http://www.apwg.org/reports/APWG_GlobalPhishingSurvey_1H2011.pdf Lots of statistics on phishing, such as a significant rise in attacks compa= red to the previous six months, which was largely due to attacks on Chinese= organisations and their customers. One thing I found interesting, and which prompted me to post about it here,= is that only 2% of the phishing domains contained the brand name of a vari= ation thereof (e.g. paypaI dot com) and they've only seen two examples of p= hishing attacks using IDNs and homographs (e.g. f=E1cebook dot com) in sinc= e 2007. Also, only 18% of the domains used (down from 28%) were registered by the p= hishers themselves; the other domains were hacked or compromised. It suggests that phishers do care about the reputation of domains as used b= y email/web filters (does the domain have a history of legitimate content?)= , but little about reputation among users (does the domain look like the on= e I expect for this site?). I'm not sure about their definition of 'phishing'. This could have some inf= luence on their statistics. Martijn. Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. _______________________________________________ Asrg mailing list Asrg@irtf.org http://www.irtf.org/mailman/listinfo/asrg From dhc@dcrocker.net Tue Dec 13 07:33:34 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 4280A21F8492 for ; Tue, 13 Dec 2011 07:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWiUzml6r9F3 for ; Tue, 13 Dec 2011 07:33:33 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A352C21F84A1 for ; Tue, 13 Dec 2011 07:33:33 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBDFXRCY025325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Dec 2011 07:33:32 -0800 Message-ID: <4EE77044.7040103@dcrocker.net> Date: Tue, 13 Dec 2011 07:33:24 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "David F. Skoll" References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> In-Reply-To: <20111112214429.0a27881b@shishi.roaringpenguin.com> 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, 13 Dec 2011 07:33:33 -0800 (PST) Cc: domainrep@ietf.org Subject: Re: [domainrep] Appropriate choice of identity 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: Tue, 13 Dec 2011 15:33:34 -0000 Folks, On 11/13/2011 10:44 AM, David F. Skoll wrote: > Just a question that may seem strange or naive at this stage, but: > > Who decided that a domain name is an appropriate identity for reputation > with respect to email? Unless I missed it, there does not seem to be a response to your original question. The thread that ensued was perhaps interesting, but I didn't see it answer this. At the beginning of an activity like the Repute working group, it's often useful to explore these sorts of foundational questions. They can, of course, become distracting, but a bit of exploration by the group might help folks develop a better, shared sense of what motivates the group's work. Getting that into the mailing list archive can also be helpful for other folks, later. (One can also imagine the result of such a discussion helping to flesh out the Introduction to a background or framework document, such as our own -model.) So... why a domain name? He's my own effort to prime the pump on the background for this effort... In terms of the mechanics of fielding exemplar uses, both SPF and Domainkeys (Yahoo!) are early examples of various folk deciding to use domain names, with quite a bit of the anti-abuse technical community lining up in support of that choice as time progressed. I don't recall seeing any real controversy about the choice, within that community. Problem with existing practice: IP Addresses --------------------------------------------- IP Addresses have been the dominant identifier in the anti-abuse game. It is available at connection setup time and it has some degree of validation, by virtue of being supplied out of band. However there are some very serious drawbacks in the choice: * Instability -- Since they are linked to network topology rather than organizational boundaries; they typically belong to the organization's service provider and not the organization, and they get re-assigned. * Ambiguity -- They often cover multiple users/organizations and therefore create ambiguity in the reputation analysis. * Obscurity -- IPv6 introduces an additional, looming nightmare for use of IP Addresses as reputation identifiers; it massively increased address space provides much greater opportunity for bad actors to hide, by using new addresses at a high rate. * Spoofing -- Although not common, IP Addresses can be spoofed. Choosing an Alternative: Domain Names -------------------------------------- Now to the theoretical phase of the question, which goes something like "so, why use domain names"? A passive aggressive response is "what other choice is there, given that IP Addresses are problematic?" It leaves the task of proposing and promoting an alternative to the questioner. As a debating technique, that's a useful approach, but it's not very helpful for developing a shared understanding of the issue. Domain names are the Internet's universal identifier for organizations. That is, their administration and use aligns well with organizational boundaries. Operationally, they have demonstrated superb scaling properties. Email addresses are the universal identifier for individuals and are based on domain names. (Even systems such as Facebook and LinkedIn, with their own namespace, are starting to support external identifiers, based on domain names, such as through OpenID.) Choosing an organizational scope for anti-abuse identifiers turns out to make things dramatically more tractable operationally. In addition, it seems to line up better in terms of distinguishing boundaries of trust and abuse. Domain names have a rich OA&M base, which provides a very high point of departure for a new application, such as reputation work. Lots of software, services and procedures can be re-used. What have I missed? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dfs@roaringpenguin.com Tue Dec 13 07:55:50 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 D17F121F8AF2 for ; Tue, 13 Dec 2011 07:55:50 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsEsZB7uzZK5 for ; Tue, 13 Dec 2011 07:55:50 -0800 (PST) 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 E92BC21F85B9 for ; Tue, 13 Dec 2011 07:55:49 -0800 (PST) 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 pBDFtiqY003305 for ; Tue, 13 Dec 2011 10:55:46 -0500 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id pBDFtfN5028305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Dec 2011 10:55:43 -0500 Date: Tue, 13 Dec 2011 10:55:40 -0500 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111213105540.456d3a5d@hydrogen.roaringpenguin.com> In-Reply-To: <4EE77044.7040103@dcrocker.net> References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> <4EE77044.7040103@dcrocker.net> 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=j37vTkLBokeC uKH45H+Ftwgg6Ew=; b=MIrfnDnHgZdxoc0Suv2UjgEzY4R80AeeeWKbkJXmIwGa 7vf4MbpK5cmt6SAqkmhTbwiieWKP0nnpOC7C3KTdK5wdoS9AqmcLPHXbSaLht33u vCIqPr9aCukb2wqbnb3NvIK9RonGOfLLzPSu4vQq+gKk4x+0y2Y2uJpQmQpFPWM= 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/20111213 / 01G8DTJC4 Subject: Re: [domainrep] Appropriate choice of identity 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: Tue, 13 Dec 2011 15:55:50 -0000 On Tue, 13 Dec 2011 07:33:24 -0800 Dave CROCKER wrote: > He's my own effort to prime the pump on the background for this > effort... [... Excellent argument ...] > Choosing an organizational scope for anti-abuse identifiers turns out > to make things dramatically more tractable operationally. In > addition, it seems to line up better in terms of distinguishing > boundaries of trust and abuse. Thanks, that's what I was looking for. But there's one thing about domain names that makes them a problem: They are extremely cheap. So what will happen in practice is that domain names will end up being lumped into three reputation classes: 1) A few very good reputation domains (paypal.com, ebay.com, big-bank.example.com, etc.) run by large institutions with a vested interest in keeping their reputations good and in using technologies like DKIM and SPF to reduce the chances of someone else successfully spoofing the domain. 2) A few neutral domains (hotmail.com, yahoo.com, gmail.com) that offer services to large numbers of users and can't really control what they do. 3) A vast population of domains with unknown reputations. Now, (1) and (2) are certainly useful, but my feeling is that IP address reputation will continue to be used extensively because it's more expensive to obtain an IP address (even an IPv6 block) than a domain and relatively expensive to change it frequently---you either have to have money or a botnet. Also, there's a danger that people will become suspicious of domains in (3) and start penalizing small/unknown domains without a sound basis for doing so. Regards, David. From dhc@dcrocker.net Tue Dec 13 08:47: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 DB9DA21F854D for ; Tue, 13 Dec 2011 08:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvNbrHAqCpvT for ; Tue, 13 Dec 2011 08:47:04 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id EABF921F84D6 for ; Tue, 13 Dec 2011 08:47:04 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBDGkwOS026863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Dec 2011 08:47:04 -0800 Message-ID: <4EE7817F.6000305@dcrocker.net> Date: Tue, 13 Dec 2011 08:46:55 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "David F. Skoll" References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> <4EE77044.7040103@dcrocker.net> <20111213105540.456d3a5d@hydrogen.roaringpenguin.com> In-Reply-To: <20111213105540.456d3a5d@hydrogen.roaringpenguin.com> 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, 13 Dec 2011 08:47:04 -0800 (PST) Cc: domainrep@ietf.org Subject: Re: [domainrep] Appropriate choice of identity 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: Tue, 13 Dec 2011 16:47:06 -0000 On 12/13/2011 7:55 AM, David F. Skoll wrote: > But there's one thing about domain > names that makes them a problem: They are extremely cheap. Interesting point. In effect, this particular downside is equivalent for domain names and IPv6 addresses, in that the namespace is so large a new name could plausibly be used with each new message. > 1) A few very good reputation domains (paypal.com, ebay.com, > big-bank.example.com, etc.) run by large institutions with a vested ... > 2) A few neutral domains (hotmail.com, yahoo.com, gmail.com) that offer > services to large numbers of users and can't really control what they do. > > 3) A vast population of domains with unknown reputations. This presumes that the mass of organizations who host their own mail -- or, rather, who send mail under their own domain name -- will not develop their own, stable reputation. By way of example, I've sent mail under bbiw.net and dcrocker.net for considerably more than a decade. I'd expect that to have established the reputations of the two domains quite solidly, one way or the other. I don't know whether their are thousands or millions of equivalent domains, but I suspect my example applies to most such domains. > Now, (1) and (2) are certainly useful, but my feeling is that IP > address reputation will continue to be used extensively because it's > more expensive to obtain an IP address (even an IPv6 block) than a > domain and relatively expensive to change it frequently---you either > have to have money or a botnet. Predicting the future is always a challenge, since there are so many reasonable scenarios. You are offering one; I think it's plausible but not necessarily correct. At a minimum, the line of concern you are raising highlights the need for an effort like this to be extremely careful and clear to make the case for its value proposition over alternatives. > Also, there's a danger that people will become suspicious of domains > in (3) and start penalizing small/unknown domains without a sound > basis for doing so. You think the market of mail receivers might act emotionally? Wow, that never happens... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From stpeter@stpeter.im Tue Dec 13 08:49:37 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 588B721F853A for ; Tue, 13 Dec 2011 08:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.052 X-Spam-Level: X-Spam-Status: No, score=-103.052 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD7R+PQzZfXn for ; Tue, 13 Dec 2011 08:49:37 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E907221F84D5 for ; Tue, 13 Dec 2011 08:49:36 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 33B6A4236A; Tue, 13 Dec 2011 09:57:11 -0700 (MST) Message-ID: <4EE7821F.9010408@stpeter.im> Date: Tue, 13 Dec 2011 09:49:35 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> <4EE77044.7040103@dcrocker.net> <20111213105540.456d3a5d@hydrogen.roaringpenguin.com> <4EE7817F.6000305@dcrocker.net> In-Reply-To: <4EE7817F.6000305@dcrocker.net> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] Appropriate choice of identity 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: Tue, 13 Dec 2011 16:49:37 -0000 On 12/13/11 9:46 AM, Dave CROCKER wrote: > > > On 12/13/2011 7:55 AM, David F. Skoll wrote: >> But there's one thing about domain >> names that makes them a problem: They are extremely cheap. > > Interesting point. In effect, this particular downside is equivalent > for domain names and IPv6 addresses, in that the namespace is so large a > new name could plausibly be used with each new message. > > >> 1) A few very good reputation domains (paypal.com, ebay.com, >> big-bank.example.com, etc.) run by large institutions with a vested > ... >> 2) A few neutral domains (hotmail.com, yahoo.com, gmail.com) that offer >> services to large numbers of users and can't really control what >> they do. >> >> 3) A vast population of domains with unknown reputations. > > This presumes that the mass of organizations who host their own mail -- > or, rather, who send mail under their own domain name -- will not > develop their own, stable reputation. > > By way of example, I've sent mail under bbiw.net and dcrocker.net for > considerably more than a decade. I'd expect that to have established > the reputations of the two domains quite solidly, one way or the other. > I don't know whether their are thousands or millions of equivalent > domains, but I suspect my example applies to most such domains. Agreed. I don't understand why good reputations would adhere only to large institutions. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Tue Dec 13 10:45: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 5FBC221F8B0B for ; Tue, 13 Dec 2011 10:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uFQu8sZdcZX for ; Tue, 13 Dec 2011 10:45:38 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id D2F5B21F8AB9 for ; Tue, 13 Dec 2011 10:45:38 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Dec 2011 10:45:32 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Dec 2011 10:45:31 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 13 Dec 2011 10:45:30 -0800 Thread-Topic: [domainrep] Appropriate choice of identity Thread-Index: Acy5r7HFoqf2by/2QW+oqZTYeptBjgAFmv2w Message-ID: References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> <4EE77044.7040103@dcrocker.net> <20111213105540.456d3a5d@hydrogen.roaringpenguin.com> In-Reply-To: <20111213105540.456d3a5d@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] Appropriate choice of identity 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: Tue, 13 Dec 2011 18:45:39 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of David F. Skoll > Sent: Tuesday, December 13, 2011 7:56 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Appropriate choice of identity >=20 > > Choosing an organizational scope for anti-abuse identifiers turns out > > to make things dramatically more tractable operationally. In > > addition, it seems to line up better in terms of distinguishing > > boundaries of trust and abuse. >=20 > Thanks, that's what I was looking for. But there's one thing about > domain names that makes them a problem: They are extremely cheap. So > what will happen in practice is that domain names will end up being > lumped into three reputation classes: >=20 > 1) A few very good reputation domains (paypal.com, ebay.com, > big-bank.example.com, etc.) run by large institutions with a vested > interest in keeping their reputations good and in using > technologies like DKIM and SPF to reduce the chances of someone > else successfully spoofing the domain. >=20 > 2) A few neutral domains (hotmail.com, yahoo.com, gmail.com) that offer > services to large numbers of users and can't really control what > they do. >=20 > 3) A vast population of domains with unknown reputations. In my own experience building a DKIM-based reputation system, there are rea= lly only two categories: 1) ADMDs that develop and maintain good reputations 2) ADMDs for which one or more of these are true: a) they don't sign their mail b) I have little or no information about them c) their behavior is middle-of-the-road (neutral reputation) d) their behavior is historically undesirable (bad reputation) Since as you point out domain names are cheap, attracting a negative reputa= tion is trivially shed, so I don't go to any real lengths to treat a bad re= putation differently than a neutral one (though if it's convenient or cheap= to do so, I do), which is why that second group is so large. Rather, I gi= ve sites that earn and preserve positive reputations more access to "me" (w= hatever that means in context) than everyone else. It's not the case, though, that positive reputations are granted only to la= rge institutions. If you have a history of sending some signed mail and no= body complains about it, your reputation is positive, regardless of your si= ze. And ADMDs that fall in the second group aren't cut off entirety, but they g= et no preferential treatment and are lumped in with everyone else in that g= roup in terms of how they are treated. You have to distinguish yourself. In my view, this creates a more meaningful economy: It is in your best inte= rests to behave if you want access to my inboxes. That means people will w= ork hard to earn a good reputation, and work harder to keep it. That promo= tes a sanitary ecosystem all around. -MSK From msk@cloudmark.com Tue Dec 13 10:48:45 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 8E9C021F84CE for ; Tue, 13 Dec 2011 10:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5FM6TDgYuhG for ; Tue, 13 Dec 2011 10:48:45 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE7421F84BA for ; Tue, 13 Dec 2011 10:48:45 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 13 Dec 2011 10:48:45 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Tue, 13 Dec 2011 10:48:44 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Tue, 13 Dec 2011 10:48:44 -0800 Thread-Topic: [domainrep] Appropriate choice of identity Thread-Index: Acy5tt8NBAHpI4+lQ+qyXt22Zs7Z+AAEN66Q Message-ID: References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> <4EE77044.7040103@dcrocker.net> <20111213105540.456d3a5d@hydrogen.roaringpenguin.com> <4EE7817F.6000305@dcrocker.net> In-Reply-To: <4EE7817F.6000305@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] Appropriate choice of identity 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: Tue, 13 Dec 2011 18:48:45 -0000 Some of this thread, by the way, might be ideal fodder for our chartered "d= os and don'ts of reputation" informational draft. -MSK From johnl@iecc.com Tue Dec 13 11:29:59 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 C385421F8AB9 for ; Tue, 13 Dec 2011 11:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.868 X-Spam-Level: X-Spam-Status: No, score=-110.868 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkW01YJUn5Qr for ; Tue, 13 Dec 2011 11:29:59 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id 507D321F87D9 for ; Tue, 13 Dec 2011 11:29:57 -0800 (PST) Received: (qmail 93710 invoked from network); 13 Dec 2011 19:29:53 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 13 Dec 2011 19:29:53 -0000 Date: 13 Dec 2011 19:29:30 -0000 Message-ID: <20111213192930.76272.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=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] Appropriate choice of identity 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: Tue, 13 Dec 2011 19:29:59 -0000 >In my own experience building a DKIM-based reputation system, there are really only two categories: > >1) ADMDs that develop and maintain good reputations > >2) ADMDs for which one or more of these are true: > [ they don't do that ] I think the assumption has always been that as various sorts of domain authentication become more widely used, people will be increasingly sceptical of mail that doesn't have a good rep. Also, it's pretty clear that IP addresses are going to be a lot harder to use for reputation. As IPv4 space runs out, you're going to see a lot of NAT with multiple customers behing the same IP address, particularly in Asia, and it'll be hard to have a single useful rep for shared IPs. Or they'll move to IPv6, where the addresses are too cheap and it is, so far, impossible to tell how many bits of an address you can attribute to a single customer. R's, John From dhc@dcrocker.net Tue Dec 13 11:31: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 85EC221F8AB9 for ; Tue, 13 Dec 2011 11:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.531 X-Spam-Level: X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wg7xYFuX0yra for ; Tue, 13 Dec 2011 11:31:04 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B72D021F87D9 for ; Tue, 13 Dec 2011 11:31:04 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBDJUx0L030309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Dec 2011 11:31:04 -0800 Message-ID: <4EE7A7EF.7020904@dcrocker.net> Date: Tue, 13 Dec 2011 11:30:55 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "domainrep@ietf.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, 13 Dec 2011 11:31:04 -0800 (PST) Subject: [domainrep] Considering COAP X-BeenThere: domainrep@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Dave Crocker List-Id: Domain Reputation discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2011 19:31:05 -0000 Folks, At the Taipei wg meeting, it was suggested that the group might want to consider use of COAP as a transport. This was specifically as an alternative to using UDP or the DNS. We took an action item to pursue this possibility. (Let's not review UDP or DNS issues in this thread; I'm mentioning them only to establish context.) Can folks comment on COAP, assuming that most of us have little background? Summaries with pointers are dandy. The first goal should be education. Also, what makes it better than, for example, using UDP? What is the state of its software packages, deployment and use? Personally I'd also be interested in some comparison to using HTTP. Thanks. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dotis@mail-abuse.org Tue Dec 13 11:34:07 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 B964021F89B8 for ; Tue, 13 Dec 2011 11:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.377 X-Spam-Level: X-Spam-Status: No, score=-102.377 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdnHyHGw7RpG for ; Tue, 13 Dec 2011 11:34:07 -0800 (PST) Received: from mailserv.mail-abuse.org (sjdc-maps-mail.trendmicro.com [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id F2F6621F891D for ; Tue, 13 Dec 2011 11:34:06 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 14E1717402CB for ; Tue, 13 Dec 2011 19:34:06 +0000 (UTC) Message-ID: <4EE7A8AD.3010902@mail-abuse.org> Date: Tue, 13 Dec 2011 11:34:05 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111031012929.44531.qmail@joyce.lan> <3C752627-E4E9-4F14-B786-DDF16EEAA556@guppylake.com> <4EBB09E6.2030302@mail-abuse.org> <715A9897-8036-48D0-844F-44760385D6C0@guppylake.com> <4EBC1E15.20409@mail-abuse.org> <4EBD936B.6020808@sonnection.nl> <4EBF0826.40209@dcrocker.net> <20111112214429.0a27881b@shishi.roaringpenguin.com> <4EE77044.7040103@dcrocker.net> In-Reply-To: <4EE77044.7040103@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Appropriate choice of identity 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: Tue, 13 Dec 2011 19:34:07 -0000 On 12/13/11 7:33 AM, Dave CROCKER wrote: > Folks, > > On 11/13/2011 10:44 AM, David F. Skoll wrote: > > Just a question that may seem strange or naive at this stage, but: > > > > Who decided that a domain name is an appropriate identity for > > reputation with respect to email? > > > Unless I missed it, there does not seem to be a response to your > original question. The thread that ensued was perhaps interesting, > but I didn't see it answer this. > > At the beginning of an activity like the Repute working group, it's > often useful to explore these sorts of foundational questions. > > They can, of course, become distracting, but a bit of exploration by > the group might help folks develop a better, shared sense of what > motivates the group's work. Getting that into the mailing list > archive can also be helpful for other folks, later. (One can also > imagine the result of such a discussion helping to flesh out the > Introduction to a background or framework document, such as our own > -model.) > > So... why a domain name? > > He's my own effort to prime the pump on the background for this > effort... > > In terms of the mechanics of fielding exemplar uses, both SPF and > Domainkeys (Yahoo!) are early examples of various folk deciding to > use domain names, with quite a bit of the anti-abuse technical > community lining up in support of that choice as time progressed. I > don't recall seeing any real controversy about the choice, within > that community. The initial desire to include SPF was to mitigate spoofed DSNs. DKIM was to mitigate phishing. Neither ensures referenced domains were accountable for specific messages received. SPF is equally problematic in conjunction with changing address topologies as would reputations directly based on the IP addresses that SPF attempts to authorize. SPF also suffers from different intended uses. Those who felt it could play a role against phishing referenced authorization from PRAs. Unfortunately, the PRA or the MAIL-FROM are often invisible in phishing attempts. When visible, it is not assured which message element referenced the SPF authorization and that this is also visible. There is also the situation of shared resources, where senders may not ensure possible authorization references are solely allocated to that of the sender. In most cases, no such allocation assurances are made. As a result, SPF permits deceptive messages that might be used in conjunction with phishing. In addition, those publishing SPF may be unable to defend against possible exploitation permitted by vague SPF references. From a receiver resource perspective, SPF may demand 111 subsequent transactions to convey all possible IPv4 and IPv6 addresses of the authorizing domain. SPF's local-part macro capability allows receiver's resources to attack any otherwise uninvolved domain that may never be seen within any message with 300 to 1 network amplification while spamming. A perfect two factor attack to evade detection and an ideal way to DDoS while spamming. :^( DKIM is also problematic. DKIM does not confirm intended recipients nor actual senders. Company A invites those interested to subscribe to their newsletter. Company B subscribes and replays Company A's newsletter using Bots sending to those who did not to injure company's A reputation. Valid DKIM signatures also permit pre-pended header fields that can change the Subject or the From seen by recipients. Such changes may deceive recipients or leverage acceptance based upon Company A's remaining and likely dwindling reputation. For SPF or DKIM, defending reputation remains problematic. The only exception will be for those considered "too big to block". Basing acceptance on the combination of DKIM AND SPF would significantly reduce delivery integrity. Basing acceptance on DKIM OR SPF would permit the exploitation of either SPF and DKIM's glaring weaknesses. > Problem with existing practice: IP Addresses > --------------------------------------------- > > IP Addresses have been the dominant identifier in the anti-abuse > game. It is available at connection setup time and it has some > degree of validation, by virtue of being supplied out of band. > However there are some very serious drawbacks in the choice: > > * Instability -- Since they are linked to network topology rather > than organizational boundaries; they typically belong to the > organization's service provider and not the organization, and they > get re-assigned. > > * Ambiguity -- They often cover multiple users/organizations and > therefore create ambiguity in the reputation analysis. Same would be true for any IP address authorization scheme, such as SPF. > * Obscurity -- IPv6 introduces an additional, looming nightmare for > use of IP Addresses as reputation identifiers; it massively increased > address space provides much greater opportunity for bad actors to > hide, by using new addresses at a high rate. Same would be true for any IP address authorization scheme, such as SPF. > * Spoofing -- Although not common, IP Addresses can be spoofed. DKIM and SPF are still more easily spoofed! > Choosing an Alternative: Domain Names > -------------------------------------- > > Now to the theoretical phase of the question, which goes something > like "so, why use domain names"? > > A passive aggressive response is "what other choice is there, given > that IP Addresses are problematic?" It leaves the task of proposing > and promoting an alternative to the questioner. As a debating > technique, that's a useful approach, but it's not very helpful for > developing a shared understanding of the issue. > > Domain names are the Internet's universal identifier for > organizations. That is, their administration and use aligns well with > organizational boundaries. Operationally, they have demonstrated > superb scaling properties. > > Email addresses are the universal identifier for individuals and are > based on domain names. (Even systems such as Facebook and LinkedIn, > with their own namespace, are starting to support external > identifiers, based on domain names, such as through OpenID.) The secure use of a domain with HTTP is normally done in conjunction with SSL certs and a CA, or perhaps a DANE RR. There is no comparable session based mechanism available for email unless one were to consider S/MIME or Open PGP. IMHO, a new SMTP Auth option could remedy this discrepancy. And yes, that would then mean reputation would be based upon those acting to issue messages stewardship in excluding those who are abusive. > Choosing an organizational scope for anti-abuse identifiers turns out > to make things dramatically more tractable operationally. In > addition, it seems to line up better in terms of distinguishing > boundaries of trust and abuse. Only when being held accountable for the actions, those who actually acted have been authenticated. This is not the case for neither DKIM nor SPF. > Domain names have a rich OA&M base, which provides a very high point > of departure for a new application, such as reputation work. Lots of > software, services and procedures can be re-used. > > What have I missed? What it takes to impose a safe and fair reputation scheme that must include the principle of basing reputation only on authenticated actors. The many avenues for exploitation are allowed by either DKIM or SPF can turn reputations into being highly disruptive. -Doug From dotis@mail-abuse.org Tue Dec 13 12:06: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 2D0C021F889A for ; Tue, 13 Dec 2011 12:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.027 X-Spam-Level: X-Spam-Status: No, score=-102.027 tagged_above=-999 required=5 tests=[AWL=-0.350, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwjRfXyoLGOJ for ; Tue, 13 Dec 2011 12:06:07 -0800 (PST) Received: from mailserv.mail-abuse.org (sjdc-maps-mail.trendmicro.com [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9B71921F8797 for ; Tue, 13 Dec 2011 12:06:07 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 3F7901740355 for ; Tue, 13 Dec 2011 20:06:07 +0000 (UTC) Message-ID: <4EE7B02E.4090803@mail-abuse.org> Date: Tue, 13 Dec 2011 12:06:06 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> In-Reply-To: <4EE7A7EF.7020904@dcrocker.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Considering COAP 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: Tue, 13 Dec 2011 20:06:08 -0000 On 12/13/11 11:30 AM, Dave CROCKER wrote: > Folks, > > At the Taipei wg meeting, it was suggested that the group might want > to consider use of COAP as a transport. This was specifically as an > alternative to using UDP or the DNS. We took an action item to pursue > this possibility. CoAP payloads seem like a good fit. Inverted JSON name space as a payload would permit simple string sorting to combine parent and child domains. :^) > (Let's not review UDP or DNS issues in this thread; I'm mentioning > them only to establish context.) > > Can folks comment on COAP, assuming that most of us have little > background? Summaries with pointers are dandy. The first goal should > be education. http://tools.ietf.org/html/draft-ietf-core-coap-03 http://tools.ietf.org/wg/core/ > Also, what makes it better than, for example, using UDP? UDP that is not DNS can be problematic. > What is the state of its software packages, deployment and use? Largely for facility automation where bandwidth requirements on low power networks requires efficient low chatty restful protocols. > Personally I'd also be interested in some comparison to using HTTP. http://tools.ietf.org/id/draft-ietf-core-link-format-09.txt -Doug From stpeter@stpeter.im Tue Dec 13 12:13: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 A80D221F8B12 for ; Tue, 13 Dec 2011 12:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.17 X-Spam-Level: X-Spam-Status: No, score=-103.17 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K-B5VyduaqB for ; Tue, 13 Dec 2011 12:13:02 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0B24D21F8B11 for ; Tue, 13 Dec 2011 12:13:02 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C3EEE4236A; Tue, 13 Dec 2011 13:20:36 -0700 (MST) Message-ID: <4EE7B1CC.1090807@stpeter.im> Date: Tue, 13 Dec 2011 13:13:00 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Dave Crocker References: <4EE7A7EF.7020904@dcrocker.net> In-Reply-To: <4EE7A7EF.7020904@dcrocker.net> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Considering COAP 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: Tue, 13 Dec 2011 20:13:02 -0000 On 12/13/11 12:30 PM, Dave CROCKER wrote: > Folks, > > At the Taipei wg meeting, it was suggested that the group might want to > consider use of COAP as a transport. This was specifically as an > alternative to using UDP or the DNS. We took an action item to pursue > this possibility. > > (Let's not review UDP or DNS issues in this thread; I'm mentioning them > only to establish context.) > > Can folks comment on COAP, assuming that most of us have little > background? Summaries with pointers are dandy. The first goal should be > education. > > Also, what makes it better than, for example, using UDP? > > What is the state of its software packages, deployment and use? > > Personally I'd also be interested in some comparison to using HTTP. I think you really want to post this message to the CORE WG, because they are the CoAP experts. As I said in Taipei, I just don't see the fit here. CoAP is designed for use by constrained devices in limited environments like home area networks and building automation systems. Using it outside that context feels inapprpriate to me. Peter -- Peter Saint-Andre https://stpeter.im/ From ajs@anvilwalrusden.com Tue Dec 13 13:05:49 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 E8AE81F0C4B for ; Tue, 13 Dec 2011 13:05:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7DrFkBjICQx for ; Tue, 13 Dec 2011 13:05:49 -0800 (PST) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 679571F0C48 for ; Tue, 13 Dec 2011 13:05:49 -0800 (PST) Received: from shinkuro.com (unknown [206.117.67.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 974511ECB41F for ; Tue, 13 Dec 2011 21:05:48 +0000 (UTC) Date: Tue, 13 Dec 2011 16:05:41 -0500 From: Andrew Sullivan To: domainrep@ietf.org Message-ID: <20111213210540.GA65553@shinkuro.com> References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EE7B1CC.1090807@stpeter.im> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [domainrep] Considering COAP 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: Tue, 13 Dec 2011 21:05:50 -0000 On Tue, Dec 13, 2011 at 01:13:00PM -0700, Peter Saint-Andre wrote: > As I said in Taipei, I just don't see the fit here. CoAP is designed for > use by constrained devices in limited environments like home area > networks and building automation systems. Using it outside that context > feels inapprpriate to me. I think if you read RFC 1034, you will find scant evidence that the DNS was designed to be expanded by underscore labels, much less the expedient of overloading an address resource record type to carry data about the reputation of a name. Yet the DNS undeniably is successfully used that way by some people. I'd like to see the analysis of CoAP. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From stpeter@stpeter.im Tue Dec 13 13:09:15 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 ADCDC21F84A0 for ; Tue, 13 Dec 2011 13:09:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.154 X-Spam-Level: X-Spam-Status: No, score=-103.154 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGH6q0bLpiFc for ; Tue, 13 Dec 2011 13:09:15 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1720621F8487 for ; Tue, 13 Dec 2011 13:09:15 -0800 (PST) Received: from dhcp-64-101-72-124.cisco.com (unknown [64.101.72.124]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id ADD824236A; Tue, 13 Dec 2011 14:16:49 -0700 (MST) Message-ID: <4EE7BEF8.4050203@stpeter.im> Date: Tue, 13 Dec 2011 14:09:12 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Andrew Sullivan References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <20111213210540.GA65553@shinkuro.com> In-Reply-To: <20111213210540.GA65553@shinkuro.com> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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: Tue, 13 Dec 2011 21:09:15 -0000 On 12/13/11 2:05 PM, Andrew Sullivan wrote: > On Tue, Dec 13, 2011 at 01:13:00PM -0700, Peter Saint-Andre wrote: > >> As I said in Taipei, I just don't see the fit here. CoAP is designed for >> use by constrained devices in limited environments like home area >> networks and building automation systems. Using it outside that context >> feels inapprpriate to me. > > I think if you read RFC 1034, you will find scant evidence that the > DNS was designed to be expanded by underscore labels, much less the > expedient of overloading an address resource record type to carry data > about the reputation of a name. Yet the DNS undeniably is > successfully used that way by some people. I'd like to see the > analysis of CoAP. Then I suggest that you ask something like this on the CORE WG list: "over in the REPUTE WG we're thinking about using CoAP to communicate reputation information over the world-wide about identifiers such as domain names, IP addresses, and email addresses; do you CoAP experts think that's an appropriate use of CoAP?" Peter -- Peter Saint-Andre https://stpeter.im/ From dotis@mail-abuse.org Tue Dec 13 15:05: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 9CCF211E80AD; Tue, 13 Dec 2011 15:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.91 X-Spam-Level: X-Spam-Status: No, score=-101.91 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGaEUq9V0tmf; Tue, 13 Dec 2011 15:05:16 -0800 (PST) Received: from mailserv.mail-abuse.org (sjdc-maps-mail.trendmicro.com [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id 48D0C11E80A4; Tue, 13 Dec 2011 15:05:16 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EE0E01740363; Tue, 13 Dec 2011 23:05:15 +0000 (UTC) Message-ID: <4EE7DA2A.3000704@mail-abuse.org> Date: Tue, 13 Dec 2011 15:05:14 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: core@ietf.org, Carsten Bormann , Cullen Jennings , domainrep References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> In-Reply-To: <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [domainrep] Suitability of CoAP in supporting domain reputation queries as an alternative to DNS. 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: Tue, 13 Dec 2011 23:05:16 -0000 CoRE WG, Please note, this message is cross posted with the Repute WG mailing-list. The Repute WG seeks help in deciding whether CoAP offers a good solution for distribution of reputation reports that assess various message identities, such as those used within email. The current state of art uses DNS and "._label." to extend queries appended to the service domain. Often the extended query describes a domain being queried along with possible scopes. In addition, information returned is fairly undefined, although details might become rather extensive. These details might include various categories known about the identity, such as involvement with financial transactions, relative volume assessments, incident reports, etc. To get the ball rolling, it seems the restful nature of CoAP will work well in conjunction with Akamai like services. Section 2.3 of Constrained Application Protocol CoAP, defines response caching in addition to mapping between HTTP and CoAP. While the message format is defined using TLV structures, the payload could include JSON structures if desired. CoAP is bound to UDP and offers a minimum MTU of 1152 bytes that compares well against the 512 byte message size limitation often imposed on DNS. CoAP includes UTF-8 encoded strings, opaque byte sequences, variable byte non-negative integers, URI-Host, URI-Path, URI-Port, Content-Type, etc. CoAP uses 16 bit Message IDs analogous to that of the DNS Transaction ID in addition to a 1 to 8 byte optional Token. CoAP can also be secured using Datagram TLS (DTLS). -Doug From tianlinyi@huawei.com Tue Dec 13 19:20:59 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 3266B11E8093 for ; Tue, 13 Dec 2011 19:20:59 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 079EQMHZxQ25 for ; Tue, 13 Dec 2011 19:20:58 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6310E11E8089 for ; Tue, 13 Dec 2011 19:20:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW600L0PBWJZP@szxga04-in.huawei.com> for domainrep@ietf.org; Wed, 14 Dec 2011 11:19:31 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW600813BVVR1@szxga04-in.huawei.com> for domainrep@ietf.org; Wed, 14 Dec 2011 11:19:30 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFR04919; Wed, 14 Dec 2011 11:19:30 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Dec 2011 11:19:26 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.108]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0323.003; Wed, 14 Dec 2011 11:19:29 +0800 Date: Wed, 14 Dec 2011 03:19:28 +0000 From: TianLinyi In-reply-to: <20111213210540.GA65553@shinkuro.com> X-Originating-IP: [10.70.109.97] To: Andrew Sullivan , "domainrep@ietf.org" Message-id: <3615F3CCD55F054395A882F51C6E5FDA18221EF3@szxeml513-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [domainrep] Considering COAP Thread-index: AQHMuc3EjxXEeCQf1UaDIiDc1wZHgJXZrYAAgAAOuYCAAO4XMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <20111213210540.GA65553@shinkuro.com> Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 03:20:59 -0000 Hi, All +1 CoAP is suitable for constrained devices but it doesn't mean it can't be used in non constrained environment. There are already some efforts to use it in mobile phone outside ietf. It would be interesting to investigate how to use CoAP in REPUTE. Cheers, Linyi -----Original Message----- From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Andrew Sullivan Sent: Wednesday, December 14, 2011 5:06 AM To: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP On Tue, Dec 13, 2011 at 01:13:00PM -0700, Peter Saint-Andre wrote: > As I said in Taipei, I just don't see the fit here. CoAP is designed for > use by constrained devices in limited environments like home area > networks and building automation systems. Using it outside that context > feels inapprpriate to me. I think if you read RFC 1034, you will find scant evidence that the DNS was designed to be expanded by underscore labels, much less the expedient of overloading an address resource record type to carry data about the reputation of a name. Yet the DNS undeniably is successfully used that way by some people. I'd like to see the analysis of CoAP. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ domainrep mailing list domainrep@ietf.org https://www.ietf.org/mailman/listinfo/domainrep From tianlinyi@huawei.com Tue Dec 13 19:23:22 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 6D95321F8436 for ; Tue, 13 Dec 2011 19:23:22 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6LJ35bCYuOLi for ; Tue, 13 Dec 2011 19:23:21 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 98D0B21F8434 for ; Tue, 13 Dec 2011 19:23:21 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW6001CYC2RG2@szxga05-in.huawei.com> for domainrep@ietf.org; Wed, 14 Dec 2011 11:23:16 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LW600MY4C2MGH@szxga05-in.huawei.com> for domainrep@ietf.org; Wed, 14 Dec 2011 11:23:15 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFR05315; Wed, 14 Dec 2011 11:23:14 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 14 Dec 2011 11:23:11 +0800 Received: from SZXEML513-MBS.china.huawei.com ([169.254.6.108]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 14 Dec 2011 11:23:07 +0800 Date: Wed, 14 Dec 2011 03:23:07 +0000 From: TianLinyi In-reply-to: <4EE7BEF8.4050203@stpeter.im> X-Originating-IP: [10.70.109.97] To: Peter Saint-Andre , Andrew Sullivan Message-id: <3615F3CCD55F054395A882F51C6E5FDA18221F19@szxeml513-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [domainrep] Considering COAP Thread-index: AQHMuc3EjxXEeCQf1UaDIiDc1wZHgJXZrYAAgAAOuYCAAAD7AIAA7glg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <20111213210540.GA65553@shinkuro.com> <4EE7BEF8.4050203@stpeter.im> Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 03:23:22 -0000 Hi, All There are already some debate on "lightweight protocol for all devices" or "protocol only for lightweight(constrained devices". I would think CoAP was originally designed for approach 2 but it doesn't limit people to use it in approach one. As peter mentioned it would be good to get opinions from CoAP folks. As one of them, my opinion is above. Cheers, Linyi -----Original Message----- From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On Behalf Of Peter Saint-Andre Sent: Wednesday, December 14, 2011 5:09 AM To: Andrew Sullivan Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP On 12/13/11 2:05 PM, Andrew Sullivan wrote: > On Tue, Dec 13, 2011 at 01:13:00PM -0700, Peter Saint-Andre wrote: > >> As I said in Taipei, I just don't see the fit here. CoAP is designed for >> use by constrained devices in limited environments like home area >> networks and building automation systems. Using it outside that context >> feels inapprpriate to me. > > I think if you read RFC 1034, you will find scant evidence that the > DNS was designed to be expanded by underscore labels, much less the > expedient of overloading an address resource record type to carry data > about the reputation of a name. Yet the DNS undeniably is > successfully used that way by some people. I'd like to see the > analysis of CoAP. Then I suggest that you ask something like this on the CORE WG list: "over in the REPUTE WG we're thinking about using CoAP to communicate reputation information over the world-wide about identifiers such as domain names, IP addresses, and email addresses; do you CoAP experts think that's an appropriate use of CoAP?" Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ domainrep mailing list domainrep@ietf.org https://www.ietf.org/mailman/listinfo/domainrep From leifj@mnt.se Wed Dec 14 00:29:40 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 6575921F88B6 for ; Wed, 14 Dec 2011 00:29:40 -0800 (PST) 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_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2FdpetDKguN for ; Wed, 14 Dec 2011 00:29:40 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9CDEB21F87FA for ; Wed, 14 Dec 2011 00:29:39 -0800 (PST) Received: from [192.168.49.23] ([84.35.81.2]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBE8TRWE024148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2011 09:29:37 +0100 (CET) Message-ID: <4EE85E67.9090001@mnt.se> Date: Wed, 14 Dec 2011 09:29:27 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> In-Reply-To: <4EE7B1CC.1090807@stpeter.im> X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 08:29:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/13/2011 09:13 PM, Peter Saint-Andre wrote: > On 12/13/11 12:30 PM, Dave CROCKER wrote: >> Folks, >> >> At the Taipei wg meeting, it was suggested that the group might >> want to consider use of COAP as a transport. This was >> specifically as an alternative to using UDP or the DNS. We took >> an action item to pursue this possibility. >> >> (Let's not review UDP or DNS issues in this thread; I'm >> mentioning them only to establish context.) >> >> Can folks comment on COAP, assuming that most of us have little >> background? Summaries with pointers are dandy. The first goal >> should be education. >> >> Also, what makes it better than, for example, using UDP? >> >> What is the state of its software packages, deployment and use? >> >> Personally I'd also be interested in some comparison to using >> HTTP. > > I think you really want to post this message to the CORE WG, > because they are the CoAP experts. > > As I said in Taipei, I just don't see the fit here. CoAP is > designed for use by constrained devices in limited environments > like home area networks and building automation systems. Using it > outside that context feels inapprpriate to me. I agree. I firmly believe we should stick firmly to the mainstream in this WG and that means REST+JSON today. This doesn't need to be more complicated than that. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7oXmcACgkQ8Jx8FtbMZndTIACeO5QxhGqPPUkfH+zU+0+tvxBY 9KQAn06YRWFga/ofJ9g8q3j49ZcmFkZr =InwI -----END PGP SIGNATURE----- From cabo@tzi.org Wed Dec 14 02:43:17 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 41D6221F8B54; Wed, 14 Dec 2011 02:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE7QnNU6LHoU; Wed, 14 Dec 2011 02:43:16 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1455821F8B5C; Wed, 14 Dec 2011 02:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pBEAh3UG026545; Wed, 14 Dec 2011 11:43:03 +0100 (CET) Received: from [192.168.217.112] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 1836C3A9; Wed, 14 Dec 2011 11:43:03 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: Carsten Bormann In-Reply-To: <4EE7DA2A.3000704@mail-abuse.org> Date: Wed, 14 Dec 2011 11:43:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5CCD2AD0-1949-4EB0-8C69-72DB410C9BAB@tzi.org> References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> <4EE7DA2A.3000704@mail-abuse.org> To: Douglas Otis X-Mailer: Apple Mail (2.1251.1) Cc: domainrep , "core@ietf.org WG" Subject: Re: [domainrep] Suitability of CoAP in supporting domain reputation queries as an alternative to DNS. 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, 14 Dec 2011 10:43:17 -0000 Hi Doug, thanks for taking to the mailing list what so far has happened mostly in = the IETF hallways. To really answer this question, it would be useful to examine some = documentation about your objectives ("requirements"). Until that happens, let me offer some observations. To a first level of approximation, CoAP provides the same service HTTP = does. If HTTP could solve your problem (performance considerations aside), and = the problem is simple enough for the simple-minded protocol that CoAP = is, then CoAP might be a good match. In particular, requests are based on URIs, and payloads make use of the = media type ("MIME type") architecture, so different kinds of resource = representations can be transferred. Of course, there are some differences to HTTP. As you note, CoAP is UDP-based, so it is indeed possible to build CoAP = servers that are completely stateless (not even keeping anything like = TCP state). For resource representations that are larger than the ~1KiB size that = can meaningfully be transported in one packet, we have the CoAP block = scheme. This still stays completely stateless on the server. = Fragmentation is never needed. (CoAP-block is not the optimal solution = for, say, retrieving a video, but variable-size things where a good part = of the distribution is inside a KiB work very well, with zero overhead = for the =E2=89=A4 ~ 1 KiB case.) On the security front, I have the following observations: -- we completely rely on lower- or higher-layer security if any is = needed. Higher-layer security could be object security (think CMS or = JOSE). For lower-layer security (i.e., communication security), our = mandatory-to-implement scheme is DTLS. Without knowing your = requirements on authentication, confidentiality etc., I have to stop = here. -- being based on UDP, CoAP has the same kind of amplification = properties that other protocols like DNS have, so Internet-facing CoAP = servers must be prepared to be implicated in DoS attacks. (This is = mitigated a bit by the ease of building a CoAP server such that it never = responds with more packets than it gets.) CoAP supports the same style of caching architecture that HTTP does -- = again, knowing more about your objectives would help us find out whether = this is a good match. We have defined CoAP to support REST on simple-minded nodes and = networks. The resulting simplicity is likely to bring some advantages = outside our space. We haven't really explored that, though (and as a = WG, we are chartered to focus on the inside). Gr=C3=BC=C3=9Fe, Carsten On Dec 14, 2011, at 00:05, Douglas Otis wrote: > CoRE WG, >=20 > Please note, this message is cross posted with the Repute WG = mailing-list. >=20 > The Repute WG seeks help in deciding whether CoAP offers a good = solution for distribution of reputation reports that assess various = message identities, such as those used within email. >=20 > The current state of art uses DNS and = "._label." to extend queries appended to the = service domain. Often the extended query describes a domain being = queried along with possible scopes. In addition, information returned = is fairly undefined, although details might become rather extensive. = These details might include various categories known about the identity, = such as involvement with financial transactions, relative volume = assessments, incident reports, etc. >=20 > To get the ball rolling, it seems the restful nature of CoAP will work = well in conjunction with Akamai like services. Section 2.3 of = Constrained Application Protocol CoAP, defines response caching in = addition to mapping between HTTP and CoAP. While the message format is = defined using TLV structures, the payload could include JSON structures = if desired. CoAP is bound to UDP and offers a minimum MTU of 1152 bytes = that compares well against the 512 byte message size limitation often = imposed on DNS. CoAP includes UTF-8 encoded strings, opaque byte = sequences, variable byte non-negative integers, URI-Host, URI-Path, = URI-Port, Content-Type, etc. CoAP uses 16 bit Message IDs analogous to = that of the DNS Transaction ID in addition to a 1 to 8 byte optional = Token. CoAP can also be secured using Datagram TLS (DTLS). >=20 > -Doug >=20 >=20 >=20 >=20 >=20 >=20 From dhc@dcrocker.net Wed Dec 14 05:41:57 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 5F36E21F8B30 for ; Wed, 14 Dec 2011 05:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.534 X-Spam-Level: X-Spam-Status: No, score=-7.534 tagged_above=-999 required=5 tests=[AWL=1.065, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jBVXus3RV2a for ; Wed, 14 Dec 2011 05:41:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E311521F8B2B for ; Wed, 14 Dec 2011 05:41:55 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBEDfolf020543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2011 05:41:55 -0800 Message-ID: <4EE8A79A.1080808@dcrocker.net> Date: Wed, 14 Dec 2011 05:41:46 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> In-Reply-To: <4EE85E67.9090001@mnt.se> 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, 14 Dec 2011 05:41:55 -0800 (PST) Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 13:41:57 -0000 >> As I said in Taipei, I just don't see the fit here. CoAP is >> > designed for ... > I agree. I should clarify that my question was not meant as a poll of preferences for or against using CoAP, but as an invitation to discuss technical merits. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Wed Dec 14 05:59: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 B610D21F8A7B for ; Wed, 14 Dec 2011 05:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ee2ilHM1fIw for ; Wed, 14 Dec 2011 05:59:15 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id E80A121F8A71 for ; Wed, 14 Dec 2011 05:59:15 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBEDxAGA020947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2011 05:59:15 -0800 Message-ID: <4EE8ABAA.6090006@dcrocker.net> Date: Wed, 14 Dec 2011 05:59:06 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "domainrep@ietf.org" References: <4EE7A7EF.7020904@dcrocker.net> In-Reply-To: <4EE7A7EF.7020904@dcrocker.net> 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, 14 Dec 2011 05:59:15 -0800 (PST) Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 13:59:16 -0000 David Dagon forwarded a list of relevant links: Standards, et al: http://tools.ietf.org/html/draft-shelby-core-coap-01 http://trac.tools.ietf.org/wg/core/trac/wiki/PlugFest Papers, studies, blogs: http://people.inf.ethz.ch/mkovatsc/#pro http://zachshelby.org/ http://lucato.it/CoAP Tools: http://sourceforge.net/projects/libcoap/ http://anonsvn.wireshark.org/wireshark/trunk/epan/dissectors/packet-coap.c d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From cabo@tzi.org Wed Dec 14 06:08:17 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 0AF1921F899D for ; Wed, 14 Dec 2011 06:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwG5I6Zp3Q52 for ; Wed, 14 Dec 2011 06:08:16 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 16CB521F8770 for ; Wed, 14 Dec 2011 06:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pBEE84cY000622; Wed, 14 Dec 2011 15:08:04 +0100 (CET) Received: from [192.168.217.110] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 72A06565; Wed, 14 Dec 2011 15:08:04 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: <4EE8ABAA.6090006@dcrocker.net> Date: Wed, 14 Dec 2011 15:08:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EE7A7EF.7020904@dcrocker.net> <4EE8ABAA.6090006@dcrocker.net> To: dcrocker@bbiw.net X-Mailer: Apple Mail (2.1251.1) Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 14:08:17 -0000 On Dec 14, 2011, at 14:59, Dave CROCKER wrote: > http://tools.ietf.org/html/draft-shelby-core-coap-01 That is an 18 months old individual draft. You want to look at the WG document: http://tools.ietf.org/html/draft-ietf-core-coap On the tools side, Matthias Kovatsch (you already linked to him) has = some more amazing stuff, including a firefox plugin called "Copper". http://people.inf.ethz.ch/mkovatsc/ Gr=FC=DFe, Carsten From msk@cloudmark.com Wed Dec 14 06:37: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 218B521F8B26 for ; Wed, 14 Dec 2011 06:37:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.283 X-Spam-Level: X-Spam-Status: No, score=-102.283 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQC04aUr-DhI for ; Wed, 14 Dec 2011 06:37:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id C280F21F8B1C for ; Wed, 14 Dec 2011 06:37:01 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 06:37:01 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 14 Dec 2011 06:37:01 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 14 Dec 2011 06:37:03 -0800 Thread-Topic: Authentication (was RE: [domainrep] Considering COAP) Thread-Index: Acy6OovxGNcs0KS5Teue7ssnxP36NAAMwYhw Message-ID: References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> In-Reply-To: <4EE85E67.9090001@mnt.se> 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: [domainrep] Authentication (was RE: Considering COAP) 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, 14 Dec 2011 14:37:02 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Leif Johansson > Sent: Wednesday, December 14, 2011 12:29 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] Considering COAP >=20 > I agree. I firmly believe we should stick firmly to the mainstream in > this WG and that means REST+JSON today. This doesn't need to be more > complicated than that. Hi Leif, That reminds me: You had indicated in Taipei that you didn't want authentic= ation to be done the way that it's currently illustrated in the query-http = document. What's there is based on one extant implementation but may not b= e the best way, and I'm no HTTP expert so I don't (currently) know any bett= er. Can you point me to the better solution you had in mind? -MSK From R.E.Sonneveld@sonnection.nl Wed Dec 14 08:20:19 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 981FE21F8A71 for ; Wed, 14 Dec 2011 08:20:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hcxpcrq0f0S4 for ; Wed, 14 Dec 2011 08:20:18 -0800 (PST) Received: from mx10.mailtransaction.com (mx11.mailtransaction.com [88.198.59.230]) by ietfa.amsl.com (Postfix) with ESMTP id 6960D21F8B0F for ; Wed, 14 Dec 2011 08:20:18 -0800 (PST) Received: from process-dkim-sign-daemon.hydrogen.mailtransaction.com by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) id <0LW700200C1SJV00@hydrogen.mailtransaction.com>; Wed, 14 Dec 2011 17:20:17 +0100 (CET) Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by hydrogen.mailtransaction.com (Oracle Communications Messaging Exchange Server 7u4-18.01 64bit (built Jul 15 2010)) with ESMTP id <0LW700K23C1SHA00@hydrogen.mailtransaction.com>; Wed, 14 Dec 2011 17:20:16 +0100 (CET) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from a80-127-135-139.adsl.xs4all.nl (a80-127-135-139.adsl.xs4all.nl [80.127.135.139]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0LW70005AC1SK600@lion.sonnection.nl> for domainrep@ietf.org; Wed, 14 Dec 2011 17:20:16 +0100 (CET) Message-id: <4EE8CDF1.6090503@sonnection.nl> Date: Wed, 14 Dec 2011 17:25:21 +0100 From: "Rolf E. Sonneveld" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Dave Crocker References: <4EE7A7EF.7020904@dcrocker.net> In-reply-to: <4EE7A7EF.7020904@dcrocker.net> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sonnection.nl; s=2009; t=1323879617; bh=W3D1OQv8m3NlcDSxGHYJjR0Ut4mqKEfLQFfMIJGPLks=; h=MIME-version:Content-transfer-encoding:Content-type:Message-id: Date:From:To:Cc:Subject:References:In-reply-to; b=dhKFobXpzSVjOjJ0pS8IFXmg/QHkh5M4+HYlGBaxVfjJafBqdDSw042BQ49QxMa/S sxCwfB/ZTD4PInzXEAJRQY9budNNGiNFWsL9mqVV7yVQt1UxpOGCVsOq8NPzbUdDvl ptQk+6hdy7WkxJa73j9CP80YH2/R4fby8PeIms3s= X-DKIM: OpenDKIM Filter v2.1.3 hydrogen.mailtransaction.com 0LW700200C1SJV00 Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 16:20:19 -0000 On 12/13/11 8:30 PM, Dave CROCKER wrote: > Folks, > > At the Taipei wg meeting, it was suggested that the group might want > to consider use of COAP as a transport. This was specifically as an > alternative to using UDP or the DNS. We took an action item to pursue > this possibility. > > (Let's not review UDP or DNS issues in this thread; I'm mentioning > them only to establish context.) > > Can folks comment on COAP, assuming that most of us have little > background? Summaries with pointers are dandy. The first goal should > be education. > > Also, what makes it better than, for example, using UDP? > > What is the state of its software packages, deployment and use? > > Personally I'd also be interested in some comparison to using HTTP. one possible issue with CoAP (compared to the DNS and HTTP transports) might be the portnumber (5683 as per http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml). Some firewalls/ISPs will block this port and the organization that wants to set up a reputation service might not always be in control of the firewall settings. /rolf From sm@resistor.net Wed Dec 14 13:02:40 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 6F26021F8AD1 for ; Wed, 14 Dec 2011 13:02:40 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2-TaDVqcydA for ; Wed, 14 Dec 2011 13:02:38 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4978411E80A6 for ; Wed, 14 Dec 2011 13:02:38 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBEL2SgH018861 for ; Wed, 14 Dec 2011 13:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323896556; bh=HPTCOlvyeLtS1T7ES6Fhf3HMNNB7gpNGu/AypXrgutA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=t7nylKYlZiArWksid7Quw4L3cXa/m5XagU+gMkCF2ThhSGUDmdPSuogHcuJHczzXA znzFQ1iUex4M6FCCC5RywkqhODfTvdROTRMKizjgaW9HENz8kJSe4mbbTPWOanCqIh iOJ5CPqJ2ZeNPLbB/+LxqxOc+z31rep0CJ8H4swM= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323896556; bh=HPTCOlvyeLtS1T7ES6Fhf3HMNNB7gpNGu/AypXrgutA=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=HIa3N4fGaSg8NtyrKBmu37MnXxiG1E0HCrjSV5eLRZ3qk1cS+L+1M6BENiNIzDfQK De+jAxSi7IabT/rGO0bBUjfdfugehRhZkIXerhGMwgGiLIW6jz0xUEsDzZikWk/P0b a03PtmHGZ07UzDVn5tU6Lq2zTKH09hQieBtCcxnA= Message-Id: <6.2.5.6.2.20111214121836.0b00f4a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Dec 2011 12:50:53 -0800 To: domainrep@ietf.org From: SM In-Reply-To: <4EE8CDF1.6090503@sonnection.nl> References: <4EE7A7EF.7020904@dcrocker.net> <4EE8CDF1.6090503@sonnection.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:02:40 -0000 At 08:25 14-12-2011, Rolf E. Sonneveld wrote: >one possible issue with CoAP (compared to the DNS and HTTP >transports) might be the portnumber (5683 as per >http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml). >Some firewalls/ISPs will block this port and the organization that >wants to set up a reputation service might not always be in control >of the firewall settings. I heard this argument before in other working groups. It is generally about short-term deployment considerations. I suggest reading draft-bormann-coap-misc-10 and draft-ietf-core-coap-08. An interesting point is that "unlike HTTP, the cacheability of CoAP responses does not depend on the request method, but the Response Code". It's worth considering CoAP if there is expertise within the working group to work with that protocol. I don't have a strong opinion about it currently. Regards, -sm From stpeter@stpeter.im Wed Dec 14 13:08:04 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 91C5B11E80A1 for ; Wed, 14 Dec 2011 13:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.672 X-Spam-Level: X-Spam-Status: No, score=-103.672 tagged_above=-999 required=5 tests=[AWL=0.927, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36RYO7TlctxQ for ; Wed, 14 Dec 2011 13:08:03 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id D4DDB11E8089 for ; Wed, 14 Dec 2011 13:08:03 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C5188423E6; Wed, 14 Dec 2011 14:15:41 -0700 (MST) Message-ID: <4EE91031.9090106@stpeter.im> Date: Wed, 14 Dec 2011 14:08:01 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> In-Reply-To: <4EE8A79A.1080808@dcrocker.net> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:08:04 -0000 On 12/14/11 6:41 AM, Dave CROCKER wrote: > > > >>> As I said in Taipei, I just don't see the fit here. CoAP is >>> > designed for > ... >> I agree. > > > I should clarify that my question was not meant as a poll of preferences > for or against using CoAP, but as an invitation to discuss technical > merits. Technical merits to accomplish what? Are there special requirements of REPUTE that would compel us to use something other than HTTP? Peter -- Peter Saint-Andre https://stpeter.im/ From dfs@roaringpenguin.com Wed Dec 14 13:12:21 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 8FD6D21F8B4C for ; Wed, 14 Dec 2011 13:12:21 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCZTv40TKFZf for ; Wed, 14 Dec 2011 13:12:21 -0800 (PST) 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 DC80D21F8B2A for ; Wed, 14 Dec 2011 13:12:20 -0800 (PST) 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 pBELCJ11032157 for ; Wed, 14 Dec 2011 16:12:19 -0500 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id pBELCGBr027400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 14 Dec 2011 16:12:18 -0500 Date: Wed, 14 Dec 2011 16:12:15 -0500 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111214161215.13aa072e@hydrogen.roaringpenguin.com> In-Reply-To: <4EE91031.9090106@stpeter.im> References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> 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=wtzdBINXwoOP Aqi1exDrbCXou1s=; b=tRip3cpkasnIrNRS3+YQJicN4HbswmN+mYvjBDyubifA SC48UdGAF9Z9Xk9sG6C6002AWeYRZS37L5mtAXFF1fdan27akUq6X0Jyp4gumXs1 OBePkwYH4fAkIJ9/gv1tXi/2Ysp0qGr5pwYSRnRnpdsWwY8ScRkKwfSZw0xiK6g= 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/20111214 / 01G99cjkx Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:12:21 -0000 On Wed, 14 Dec 2011 14:08:01 -0700 Peter Saint-Andre wrote: > Technical merits to accomplish what? Are there special requirements of > REPUTE that would compel us to use something other than HTTP? I think so. A reputation system may receive many queries and might want to use a lightweight, completely-stateless mechanism to respond to them. Traditionally, DNS has been (ab)used for this. Regards, David. From stpeter@stpeter.im Wed Dec 14 13:15:29 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 2783221F8B55 for ; Wed, 14 Dec 2011 13:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.697 X-Spam-Level: X-Spam-Status: No, score=-102.697 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EokFOCWzaMW3 for ; Wed, 14 Dec 2011 13:15:28 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 916F121F8AC3 for ; Wed, 14 Dec 2011 13:15:28 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9594E423E6; Wed, 14 Dec 2011 14:23:06 -0700 (MST) Message-ID: <4EE911EF.4000701@stpeter.im> Date: Wed, 14 Dec 2011 14:15:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "David F. Skoll" References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> In-Reply-To: <20111214161215.13aa072e@hydrogen.roaringpenguin.com> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:15:29 -0000 On 12/14/11 2:12 PM, David F. Skoll wrote: > On Wed, 14 Dec 2011 14:08:01 -0700 > Peter Saint-Andre wrote: > >> Technical merits to accomplish what? Are there special requirements of >> REPUTE that would compel us to use something other than HTTP? > > I think so. A reputation system may receive many queries So does Twitter. :) (Hey, reputation over Twitter...) > and might want > to use a lightweight, completely-stateless mechanism to respond to them. What exactly stateful about a mere HTTP request-response pair? > Traditionally, DNS has been (ab)used for this. Indeed. That doesn't mean we can't use HTTP. Just trying to understand the requirements here... Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Wed Dec 14 13:16:21 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 5F0BE21F8B57 for ; Wed, 14 Dec 2011 13:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaxAbakzbsGq for ; Wed, 14 Dec 2011 13:16:21 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 020D821F8B56 for ; Wed, 14 Dec 2011 13:16:21 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 13:16:20 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 14 Dec 2011 13:16:19 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 14 Dec 2011 13:16:19 -0800 Thread-Topic: [domainrep] Considering COAP Thread-Index: Acy6pHzeQ8eTvNS2TjalqYieqV+VqwAAJgPg Message-ID: References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> In-Reply-To: <4EE91031.9090106@stpeter.im> 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] Considering COAP 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, 14 Dec 2011 21:16:21 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of Peter Saint-Andre > Sent: Wednesday, December 14, 2011 1:08 PM > To: dcrocker@bbiw.net > Cc: domainrep@ietf.org > Subject: Re: [domainrep] Considering COAP >=20 > Technical merits to accomplish what? Are there special requirements of > REPUTE that would compel us to use something other than HTTP? One of the oft-cited applications of reputation that exists today is Spamas= sassin, which in some configurations can fire off a dozen or more DNSBL que= ries for a single message. The idea of initiating that many HTTP queries f= or each arriving message sounds rather heavyweight to me. That's why we've= always had the idea of supporting a lightweight mechanism that just return= s a score and has all kinds of implied context established outside the prot= ocol between the client and the server (as DNSBLs do today), and a heavywei= ght one that has the capacity to be a lot more explicit about both the ques= tion and the answer. Are some of my assumptions about the heavyweight nature of HTTP/XML faulty? From stpeter@stpeter.im Wed Dec 14 13:30:33 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 37FDF11E80B9 for ; Wed, 14 Dec 2011 13:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.694 X-Spam-Level: X-Spam-Status: No, score=-102.694 tagged_above=-999 required=5 tests=[AWL=-0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvR3NDf3Kv3w for ; Wed, 14 Dec 2011 13:30:32 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 82C8B11E8089 for ; Wed, 14 Dec 2011 13:30:32 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5F71A423D8; Wed, 14 Dec 2011 14:38:10 -0700 (MST) Message-ID: <4EE91576.8010600@stpeter.im> Date: Wed, 14 Dec 2011 14:30:30 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Murray S. Kucherawy" References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "domainrep@ietf.org" Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:30:33 -0000 On 12/14/11 2:16 PM, Murray S. Kucherawy wrote: >> -----Original Message----- From: domainrep-bounces@ietf.org >> [mailto:domainrep-bounces@ietf.org] On Behalf Of Peter Saint-Andre >> Sent: Wednesday, December 14, 2011 1:08 PM To: dcrocker@bbiw.net >> Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP >> >> Technical merits to accomplish what? Are there special requirements >> of REPUTE that would compel us to use something other than HTTP? > > One of the oft-cited applications of reputation that exists today is > Spamassassin, which in some configurations can fire off a dozen or > more DNSBL queries for a single message. The idea of initiating that > many HTTP queries for each arriving message sounds rather heavyweight > to me. That's why we've always had the idea of supporting a > lightweight mechanism that just returns a score and has all kinds of > implied context established outside the protocol between the client > and the server (as DNSBLs do today), and a heavyweight one that has > the capacity to be a lot more explicit about both the question and > the answer. > > Are some of my assumptions about the heavyweight nature of HTTP/XML > faulty? Leif mentioned JSON, not XML. I'm agnostic on that here. As to HTTP, there's lots of practical experience in making those deployments scale to large numbers of requests per hour/minute, spreading the load across multiple servers, caching responses, and all the rest. I would not assume that HTTP can't do the job. Peter -- Peter Saint-Andre https://stpeter.im/ From dfs@roaringpenguin.com Wed Dec 14 13:30: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 B5E5311E80BC for ; Wed, 14 Dec 2011 13:30:44 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+0CjVswGUCz for ; Wed, 14 Dec 2011 13:30:44 -0800 (PST) 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 0CCB911E8089 for ; Wed, 14 Dec 2011 13:30:43 -0800 (PST) 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 pBELUhAk003696 for ; Wed, 14 Dec 2011 16:30:43 -0500 Received: from hydrogen.roaringpenguin.com (hydrogen.roaringpenguin.com [192.168.10.1]) by vanadium.roaringpenguin.com (8.14.3/8.14.3/Debian-9.4) with ESMTP id pBELUdxu012004 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 14 Dec 2011 16:30:40 -0500 Date: Wed, 14 Dec 2011 16:30:38 -0500 From: "David F. Skoll" To: domainrep@ietf.org Message-ID: <20111214163038.1d6da9ee@hydrogen.roaringpenguin.com> In-Reply-To: <4EE911EF.4000701@stpeter.im> References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> 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=bOjzwmoGT/To VCwUoXpBE25j1f8=; b=FjJMkaHzBlNYM0iYyjnPUF7hrqoSb2pf3AYcuwY2bg1w JIBcG2Pd5mNEmOafNGMYt1H5vAxYCFoJBYlpMmagJwSul49JOK2W/qPvsxUXdUH2 kJl4PhOXBXeTW2h+7ztR8V5PCCfLwnCTuKNvBssY+Yglrwy12ZX1ZkX0TjjVyFQ= 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/20111214 / 01G99uHl8 Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:30:44 -0000 On Wed, 14 Dec 2011 14:15:27 -0700 Peter Saint-Andre wrote: > What exactly stateful about a mere HTTP request-response pair? TCP is stateful. The end that does the active close has to hang around in TIME_WAIT state for a while. For HTTP, the server usually does the active close and a busy server could be swamped with TIME_WAIT TCP connections. Regards, David. From dhc@dcrocker.net Wed Dec 14 13:34:46 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 DFD5421F8770 for ; Wed, 14 Dec 2011 13:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.583 X-Spam-Level: X-Spam-Status: No, score=-7.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5x2LcRX3Pmzc for ; Wed, 14 Dec 2011 13:34:46 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4DCA921F85B9 for ; Wed, 14 Dec 2011 13:34:46 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBELYeha032112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Dec 2011 13:34:45 -0800 Message-ID: <4EE9166C.9050305@dcrocker.net> Date: Wed, 14 Dec 2011 13:34:36 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> In-Reply-To: <4EE91031.9090106@stpeter.im> 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, 14 Dec 2011 13:34:46 -0800 (PST) Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:34:47 -0000 On 12/14/2011 1:08 PM, Peter Saint-Andre wrote: > On 12/14/11 6:41 AM, Dave CROCKER wrote: >> I should clarify that my question was not meant as a poll of preferences >> for or against using CoAP, but as an invitation to discuss technical >> merits. > > Technical merits to accomplish what? Are there special requirements of > REPUTE that would compel us to use something other than HTTP? Peter, You are already getting responses that are in line with the basis for this sub-thread, but just to offer the first-person explanation for asking it: 1. The group already has the distinction between an http-based transport and a "lightweight" transport for smaller query/response exchanges. The logic for that distinction is, ummmm, distinct from the choice of the particular lightweight alternative. 2. CoAP was offered as an alternative to DNS or UDP based queries. Presumably there are technical differences that are interesting, among this set. My above clarification was to solicit the technical information that permits comparing CoAP to these other choices. Just doing straightforward due diligence. On a personal note, I'll comment that using HTTP as the transport for very large numbers of very small query/response exchanges is somewhere between silly and offensive, for anyone trying to pay attention to latency and overhead issues. To quote that great systems designer, Richard Nixon, "We could do it, but it would be wrong". In the real world, all sorts of 'wrong' things are done and this might turn out to be one of them. But it's worth some group time to explore alternatives. Speaking as chair I'll assure you (and everyone else) that this is not going to become a rathole in the short- or long-term... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From cabo@tzi.org Wed Dec 14 13:35:31 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 CB72A21F87D3 for ; Wed, 14 Dec 2011 13:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bOmZnw9ZCaM for ; Wed, 14 Dec 2011 13:35:31 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 807C321F8797 for ; Wed, 14 Dec 2011 13:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id pBELZMCH002176; Wed, 14 Dec 2011 22:35:22 +0100 (CET) Received: from [192.168.217.110] (p54899AAB.dip.t-dialin.net [84.137.154.171]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 19127765; Wed, 14 Dec 2011 22:35:22 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <4EE911EF.4000701@stpeter.im> Date: Wed, 14 Dec 2011 22:35:20 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1251.1) Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:35:31 -0000 On Dec 14, 2011, at 22:15, Peter Saint-Andre wrote: > What exactly stateful about a mere HTTP request-response pair? =46rom the point of view of a server operator, those TCP connections = underlying HTTP are state. In the process of answering an HTTP request the server builds up kernel = and socket state while engaging in the three-way handshake, then it uses = that state to respond to the request, and finally it needs to tear down = the state with the final FIN/ACK, causing TIME_WAIT states depending on = who does this first. This kind of state makes both plain scaling and DoS hardening harder. Gr=FC=DFe, Carsten [Just answering the question; I have no opinion on whether that is = relevant with respect to repute's objectives. E.g., the state can actually be a good thing if it helps = congestion-controlling multiple requests that occur in a row, as in HTTP = pipelining. The usual legacy arguments about HTTP pipelining don't = apply in the deployment scenarios I can imagine. =20 That is proof by lack of imagination, though. If your security objectives call for TLS/DTLS, you need to build up some = state anyway. The DoS protection may be much better with DTLS, though. =20= And so on=85 =20 I really need to know more about your objectives.] From sm@resistor.net Wed Dec 14 13:43: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 B97D721F8480 for ; Wed, 14 Dec 2011 13:43:38 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5td9LSM9qIKI for ; Wed, 14 Dec 2011 13:43:36 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A4A21F8479 for ; Wed, 14 Dec 2011 13:43:30 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBELhQL6021923 for ; Wed, 14 Dec 2011 13:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323899010; bh=Koxi+isIVzYLtdj41eqe1OqwIqagHmy/glU2bcD3pHc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Npq1o4539Yy4ojZZn+w6GA3VjNtDomCDEYQy5+eVt24H8eqFm+q2vTfeBOiRWW/an o7pmdPRg5uXjQIP/0gZDGPn8HK2RIVWVBojtU7Ez71tKSfIukbnKxj8eIakhyf7Tvt boWjs6iyNN90buQ8+1KHPcuaA1luZLF8+P4WNXxs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323899010; bh=Koxi+isIVzYLtdj41eqe1OqwIqagHmy/glU2bcD3pHc=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=aUKLaIiJ5y0UuNdYbfnocNk6AHQ7fuoLzJrUskR3RKZ+GGqZSvDFXcKAyUH4ct/5F 42/Qh/j5zHGhg4cv8rTqRwhcMBUqFGwyxjGWxOVUoAqhoDnzcSBSot8dIO48cpINFB vUbMuCtiWyMr4nSxIFjGs9OY9FG5M8BSev/ZVQwQ= Message-Id: <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Dec 2011 13:40:22 -0800 To: domainrep@ietf.org From: SM In-Reply-To: <4EE911EF.4000701@stpeter.im> References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:43:38 -0000 At 13:15 14-12-2011, Peter Saint-Andre wrote: >(Hey, reputation over Twitter...) +1 :-) >What exactly stateful about a mere HTTP request-response pair? HTTP is stateless. TCP is stateful. At 13:16 14-12-2011, Murray S. Kucherawy wrote: >One of the oft-cited applications of reputation that exists today is >Spamassassin, which in some configurations can fire off a dozen or >more DNSBL queries for a single message. Yes. > The idea of initiating that many HTTP queries for each arriving > message sounds rather heavyweight to me. That's why we've always > had the idea of supporting a lightweight mechanism that just > returns a score and has all kinds of implied context established > outside the protocol between the client and the server (as DNSBLs > do today), and a heavyweight one that has the capacity to be a lot > more explicit about both the question and the answer. The use of terms such as heavyweight and lightweight mechanisms does not provide much information. A HTTP mechanism can be optimized. That requires more work than DNS, for example, as the optimization is done at more than one layer. Points of discussion could be: (a) round-trip (b) payload size (c) cacheability Regards, -sm From stpeter@stpeter.im Wed Dec 14 13:47:13 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 362DA11E80C3 for ; Wed, 14 Dec 2011 13:47:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.692 X-Spam-Level: X-Spam-Status: No, score=-103.692 tagged_above=-999 required=5 tests=[AWL=0.907, BAYES_00=-2.599, GB_I_INVITATION=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ah58EJjfMMUk for ; Wed, 14 Dec 2011 13:47:12 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 65B1D11E80B5 for ; Wed, 14 Dec 2011 13:47:12 -0800 (PST) Received: from normz.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 41DFF423D8; Wed, 14 Dec 2011 14:54:50 -0700 (MST) Message-ID: <4EE9195E.7050600@stpeter.im> Date: Wed, 14 Dec 2011 14:47:10 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dcrocker@bbiw.net References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <4EE9166C.9050305@dcrocker.net> In-Reply-To: <4EE9166C.9050305@dcrocker.net> X-Enigmail-Version: 1.3.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:47:13 -0000 On 12/14/11 2:34 PM, Dave CROCKER wrote: > > > On 12/14/2011 1:08 PM, Peter Saint-Andre wrote: >> On 12/14/11 6:41 AM, Dave CROCKER wrote: >>> I should clarify that my question was not meant as a poll of preferences >>> for or against using CoAP, but as an invitation to discuss technical >>> merits. >> >> Technical merits to accomplish what? Are there special requirements of >> REPUTE that would compel us to use something other than HTTP? > > > Peter, > > You are already getting responses that are in line with the basis for > this sub-thread, but just to offer the first-person explanation for > asking it: > > 1. The group already has the distinction between an http-based > transport and a "lightweight" transport for smaller query/response > exchanges. The logic for that distinction is, ummmm, distinct from the > choice of the particular lightweight alternative. Agreed. > 2. CoAP was offered as an alternative to DNS or UDP based queries. > Presumably there are technical differences that are interesting, among > this set. My above clarification was to solicit the technical > information that permits comparing CoAP to these other choices. Just > doing straightforward due diligence. Yes, that's good. > On a personal note, I'll comment that using HTTP as the transport for > very large numbers of very small query/response exchanges is somewhere > between silly and offensive, for anyone trying to pay attention to > latency and overhead issues. Probably, but that doesn't stop people from doing stupid and offensive things. > To quote that great systems designer, > Richard Nixon, "We could do it, but it would be wrong". I thought Al Gore invented the Internet. :) > In the real world, all sorts of 'wrong' things are done and this might > turn out to be one of them. But it's worth some group time to explore > alternatives. For sure, I think it's a valuable exercise! > Speaking as chair I'll assure you (and everyone else) that this is not > going to become a rathole in the short- or long-term... I don't see any rat-hole here yet, just constructive discussion and probing questions. Peter -- Peter Saint-Andre https://stpeter.im/ From msk@cloudmark.com Wed Dec 14 13:53:04 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 93FBA11E80C9 for ; Wed, 14 Dec 2011 13:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhiCXDFzuJgZ for ; Wed, 14 Dec 2011 13:53:04 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 37C4711E80C6 for ; Wed, 14 Dec 2011 13:53:04 -0800 (PST) Received: from spite.corp.cloudmark.com (172.22.10.72) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 13:53:04 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by spite.corp.cloudmark.com ([172.22.10.72]) with mapi; Wed, 14 Dec 2011 13:53:03 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 14 Dec 2011 13:53:02 -0800 Thread-Topic: [domainrep] Considering COAP Thread-Index: Acy6p50Ic3NhbJTRSt63hGIckPjCcwAAvXKA Message-ID: References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <4EE91576.8010600@stpeter.im> In-Reply-To: <4EE91576.8010600@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 21:53:04 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBTYWludC1BbmRyZSBb bWFpbHRvOnN0cGV0ZXJAc3RwZXRlci5pbV0NCj4gU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciAx NCwgMjAxMSAxOjMxIFBNDQo+IFRvOiBNdXJyYXkgUy4gS3VjaGVyYXd5DQo+IENjOiBkb21haW5y ZXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkb21haW5yZXBdIENvbnNpZGVyaW5nIENPQVAN Cj4gDQo+IEFzIHRvIEhUVFAsIHRoZXJlJ3MgbG90cyBvZiBwcmFjdGljYWwgZXhwZXJpZW5jZSBp biBtYWtpbmcgdGhvc2UNCj4gZGVwbG95bWVudHMgc2NhbGUgdG8gbGFyZ2UgbnVtYmVycyBvZiBy ZXF1ZXN0cyBwZXIgaG91ci9taW51dGUsDQo+IHNwcmVhZGluZyB0aGUgbG9hZCBhY3Jvc3MgbXVs dGlwbGUgc2VydmVycywgY2FjaGluZyByZXNwb25zZXMsIGFuZCBhbGwNCj4gdGhlIHJlc3QuIEkg d291bGQgbm90IGFzc3VtZSB0aGF0IEhUVFAgY2FuJ3QgZG8gdGhlIGpvYi4NCg0KVHdvIHF1ZXN0 aW9ucyBjb21lIHRvIG1pbmQ6DQoNCjEpIERvZXMgdGhlIHNhbWUgc2NhbGFiaWxpdHkgZ28gZm9y IGNsaWVudHMsIG9yIGEgbWFpbCBzZXJ2ZXIgdGhhdCdzIHdhaXRpbmcgb24gYSBkb3plbiBvciBt b3JlIHJlcGxpZXM/DQoNCjIpIFNob3VsZCB3ZSBlbmdpbmVlciB0aGlzIGFzc3VtaW5nIHRoYXQg YWxsIEhUVFAgc2VydmVycyBhcmUgZXF1aXBwZWQgd2l0aCB0aG9zZSBvcHRpbWl6YXRpb25zPw0K From msk@cloudmark.com Wed Dec 14 13:55:00 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 AD24311E80C7 for ; Wed, 14 Dec 2011 13:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eywOCQsLWO1n for ; Wed, 14 Dec 2011 13:55:00 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3C59F11E8098 for ; Wed, 14 Dec 2011 13:55:00 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 14 Dec 2011 13:55:00 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Wed, 14 Dec 2011 13:54:59 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Wed, 14 Dec 2011 13:54:59 -0800 Thread-Topic: [domainrep] Considering COAP Thread-Index: Acy6qXvKVBCw01wJTPGa+HVreeCjvAAAXRBg Message-ID: References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> In-Reply-To: <6.2.5.6.2.20111214132118.0aaad5a8@resistor.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] Considering COAP 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, 14 Dec 2011 21:55:00 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of SM > Sent: Wednesday, December 14, 2011 1:40 PM > To: domainrep@ietf.org > Subject: Re: [domainrep] Considering COAP >=20 > The use of terms such as heavyweight and lightweight mechanisms does > not provide much information. They aren't meant to be completely descriptive, only comparative between th= emselves. From dhc@dcrocker.net Wed Dec 14 14:14:20 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 5067B21F8593 for ; Wed, 14 Dec 2011 14:14:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.626 X-Spam-Level: X-Spam-Status: No, score=-6.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei8XGnGh3JB3 for ; Wed, 14 Dec 2011 14:14:19 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEA821F8591 for ; Wed, 14 Dec 2011 14:14:19 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBEMECTL000834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 14 Dec 2011 14:14:18 -0800 Message-ID: <4EE91FB0.8000106@dcrocker.net> Date: Wed, 14 Dec 2011 14:14:08 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> In-Reply-To: <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> 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, 14 Dec 2011 14:14:19 -0800 (PST) Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 22:14:20 -0000 On 12/14/2011 1:40 PM, SM wrote: > Points of discussion could be: > > (a) round-trip > > (b) payload size > > (c) cacheability A reference like "round-trip" usually refers to a single RT latency. A separate issue is the /number/ of RTs, or "chattiness". And, thought it's not required, these two can have inverse correlation: a design environment that expects lower latencies will often produce protocols of higher chattiness. (This is the reason that WAN protocols usually translate well to LAN environments, but LAN protocols rarely translate well to WAN environments.) On 12/14/2011 1:53 PM, Murray S. Kucherawy wrote: > Two questions come to mind: > > 1) Does the same scalability go for clients, or a mail server that's waiting on a dozen or more replies? > > 2) Should we engineer this assuming that all HTTP servers are equipped with those optimizations? It's reasonable to distinguish between per-query overhead, per-message (or the like) overhead, and "aggregate" server or client overhead of the type you describe. Any serious discussion about performance and cost ought to run over all of these sorts of issues, to consider what matters and what doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From sm@resistor.net Wed Dec 14 14:14:34 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 22D2B21F856F for ; Wed, 14 Dec 2011 14:14:34 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdinGe82zRd5 for ; Wed, 14 Dec 2011 14:14:31 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BACC21F858D for ; Wed, 14 Dec 2011 14:14:31 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBEMEGpB002038; Wed, 14 Dec 2011 14:14:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323900863; bh=GRjyn46jToizTcUIaTGvvRny2r2fGhk+YkP6E8HczwM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=fifhvpr9H18RyA1EiqJfRKx4tyVFK9FLZEXe9Iqc6IXxDMkur7A0fBsEqDR2yoqVL qQVKwfuhOkhuFRc0fI0tRGeYXoHvQmr5bv1AmjhqpdlJRswBNAxBcRSvDZT5hZ45tB jH5byWNOy8f3+TYndXL/f5vZAAjRdUq+TTSRjsvE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323900863; bh=GRjyn46jToizTcUIaTGvvRny2r2fGhk+YkP6E8HczwM=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=PxBtDdbg03ytyW+KW5NyrIGiiPJEGzj1V4EpVn452dJiL+zndXfpejefeYthrxhKq CPndkMHtZ8i0KVO3i1OI36wF5ctJIsHjGIanoDZe+W8uMgygCHiRICizxpp6844tyC /+AUQd86KgJ5BhW9WQaVaL7B7j7xphYRVZdtGjio= Message-Id: <6.2.5.6.2.20111214140533.0b002a30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Dec 2011 14:10:49 -0800 To: "Murray S. Kucherawy" From: SM In-Reply-To: References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: domainrep@ietf.org Subject: Re: [domainrep] Considering COAP 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, 14 Dec 2011 22:14:34 -0000 Hi Murray, At 13:54 14-12-2011, Murray S. Kucherawy wrote: >They aren't meant to be completely descriptive, only comparative >between themselves. I owe you an apology. I understood what you meant. I was focusing on characteristics and cut down on the explanation. Regards, -sm From sm@resistor.net Wed Dec 14 16:10:37 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 21A4121F84DF for ; Wed, 14 Dec 2011 16:10:37 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bq19lHd9AB6s for ; Wed, 14 Dec 2011 16:10:35 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA90921F850B for ; Wed, 14 Dec 2011 16:10:34 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBF0A9vf002825 for ; Wed, 14 Dec 2011 16:10:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1323907816; bh=2F1zuxDol05f+gUv/CHYltevw9CVvmRaCEez7j9iM+s=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=gKXp3jLIWzaA8tqjiNX/mBYqnL1mzogUEtuDL4bcFBRifrdwOMHmDwdoEKh02Sbfd zmfKrJLXIKz3aLSPmQ+ljU9XhmRXhDztBR0Z8ZN1zf03xdp7NwSnu7U2UBo4iD2CBa RRn0IlaNSoBQgewiC9d4VeqN1nGldZfnoTLL4I4I= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1323907816; bh=2F1zuxDol05f+gUv/CHYltevw9CVvmRaCEez7j9iM+s=; h=Message-Id:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type:Cc; b=Af17TonbhBitZ6+mA4zrybumDdjnWtPjkdIfRUoCTFFw5DaPiL3j+HfR6D/W3+hWp v++0ENkSmestDGa72sW4RmWfmI6pvpjUoaYnqUUw7/i88bY+qlhqH38C7dpjpBVoSO aILy9AG204O7K+XiGQhmimPFfpvugMDeM9J7AkcE= Message-Id: <6.2.5.6.2.20111214145652.0619e1b0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 14 Dec 2011 16:10:01 -0800 To: domainrep@ietf.org From: SM In-Reply-To: <4EE91FB0.8000106@dcrocker.net> References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> <4EE91FB0.8000106@dcrocker.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [domainrep] Considering COAP 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, 15 Dec 2011 00:10:37 -0000 At 14:14 14-12-2011, Dave CROCKER wrote: >A reference like "round-trip" usually refers to a single RT latency. > >A separate issue is the /number/ of RTs, or "chattiness". Yes. >And, thought it's not required, these two can have inverse >correlation: a design environment that expects lower latencies will >often produce protocols of higher chattiness. > >(This is the reason that WAN protocols usually translate well to LAN >environments, but LAN protocols rarely translate well to WAN environments.) Yes. At 13:53 14-12-2011, Murray S. Kucherawy wrote: >2) Should we engineer this assuming that all HTTP servers are >equipped with those optimizations? When we are talking about HTTP servers, I'll assume that it is on the server side. HTTP servers are usually general-purpose. Some of the optimizations come with caveats. One of them might even be described as bordering protocol violation. Let's assume that anyone running such a service has the necessary expertise to do so. The latency issue is addressed currently by having the cache close to the client. It's not a problem as such at the moment as the recursive DNS server also provides that feature. For HTTP, you'll have to install a HTTP proxy nearby. That may end up increasing the cost. I used the term round-trip but it is incorrect. What we are looking at is actually response time. Unless one can afford the expense, a classic operation would be dealing with a response time of up to 300 ms for example. That would make filtering unworkable. If you get cacheability near or as part of the client, the occasional high response time becomes acceptable. BTW, the above covers "GET" mostly. If I recall correctly, there was also some discussion about "POSTing". Regards, -sm From dotis@mail-abuse.org Wed Dec 14 16:41:22 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 48C891F0C4F; Wed, 14 Dec 2011 16:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.313 X-Spam-Level: X-Spam-Status: No, score=-102.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrS71T4mQhpg; Wed, 14 Dec 2011 16:41:21 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id A0D931F0C47; Wed, 14 Dec 2011 16:41:21 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway1.sdi.trendnet.org [10.31.37.8]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id EF26C17404B8; Thu, 15 Dec 2011 00:41:20 +0000 (UTC) Message-ID: <4EE9422E.2030301@mail-abuse.org> Date: Wed, 14 Dec 2011 16:41:18 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Carsten Bormann References: <3AB4ED7E-F81F-47A3-85E4-F7FFE1F0A60F@koanlogic.com> <4A0ED0F3-B123-4760-94EA-9280EBA51947@tzi.org> <4EE7DA2A.3000704@mail-abuse.org> <5CCD2AD0-1949-4EB0-8C69-72DB410C9BAB@tzi.org> In-Reply-To: <5CCD2AD0-1949-4EB0-8C69-72DB410C9BAB@tzi.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: domainrep , "core@ietf.org WG" Subject: Re: [domainrep] Suitability of CoAP in supporting domain reputation queries as an alternative to DNS. 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, 15 Dec 2011 00:41:22 -0000 On 12/14/11 2:43 AM, Carsten Bormann wrote: > Hi Doug, > > thanks for taking to the mailing list what so far has happened mostly in the IETF hallways. > > To really answer this question, it would be useful to examine some documentation about your objectives ("requirements"). > Until that happens, let me offer some observations. > > To a first level of approximation, CoAP provides the same service HTTP does. > If HTTP could solve your problem (performance considerations aside), and the problem is simple enough for the simple-minded protocol that CoAP is, then CoAP might be a good match. > In particular, requests are based on URIs, and payloads make use of the media type ("MIME type") architecture, so different kinds of resource representations can be transferred. Many have suggested DNS can be (ab)used to provide URI based Get/Response exchanges where CoAP provides similar overheads. In format comparison, JSON offers advantages for moderately complex exchanges. IMHO, to retain single packet exchanges, XML and HTTP represent a poor choice, and this speaks well for CoAP. > Of course, there are some differences to HTTP. > As you note, CoAP is UDP-based, so it is indeed possible to build CoAP servers that are completely stateless (not even keeping anything like TCP state). > For resource representations that are larger than the ~1KiB size that can meaningfully be transported in one packet, we have the CoAP block scheme. This still stays completely stateless on the server. Fragmentation is never needed. (CoAP-block is not the optimal solution for, say, retrieving a video, but variable-size things where a good part of the distribution is inside a KiB work very well, with zero overhead for the ≤ ~ 1 KiB case.) When large file transfers are required, rsync offers a better solution IMHO. CoAP over UDP should be easier to deploy. Ease of deployment is likely the greatest determining factor. For mid-range services, network overhead and latency is often the greater concern. When inbound servers become overwhelmed, reputation services are intended to mitigate this which represents >90% abuse. As such caching helps which is also supported by CoAP, but unfortunately aliases used in abuse to be stealthy offer poor caching characteristics. As such, round trip times related with UDP is significantly better than what is offered by TCP. A better alternative would use SCTP data framing for sustained virtual long term sessions, but I suspect there is not enough requisite background to support this approach. > On the security front, I have the following observations: > > -- we completely rely on lower- or higher-layer security if any is needed. Higher-layer security could be object security (think CMS or JOSE). For lower-layer security (i.e., communication security), our mandatory-to-implement scheme is DTLS. Without knowing your requirements on authentication, confidentiality etc., I have to stop here. > -- being based on UDP, CoAP has the same kind of amplification properties that other protocols like DNS have, so Internet-facing CoAP servers must be prepared to be implicated in DoS attacks. (This is mitigated a bit by the ease of building a CoAP server such that it never responds with more packets than it gets.) > > CoAP supports the same style of caching architecture that HTTP does -- again, knowing more about your objectives would help us find out whether this is a good match. Some customers will want the DTLS feature. In most cases, the Token exchange would be fairly ideal for our purposes. As such, CoAP looks rather attractive. > We have defined CoAP to support REST on simple-minded nodes and networks. The resulting simplicity is likely to bring some advantages outside our space. We haven't really explored that, though (and as a WG, we are chartered to focus on the inside). I would also suspect that 99% of transactions will be Get where other transaction types would be limited to authenticated sessions and used for maintenance and updates. -Doug From clewis+ietf@mustelids.ca Wed Dec 14 22:22:22 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 A4F0F1F0C4D for ; Wed, 14 Dec 2011 22:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCElE+5RH8p3 for ; Wed, 14 Dec 2011 22:22:22 -0800 (PST) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 0B2DA1F0C3F for ; Wed, 14 Dec 2011 22:22:21 -0800 (PST) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBF6M7Oj031191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Dec 2011 01:22:09 -0500 Message-ID: <4EE9920E.9080707@mustelids.ca> Date: Thu, 15 Dec 2011 01:22:06 -0500 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <4EE91576.8010600@stpeter.im> In-Reply-To: <4EE91576.8010600@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Considering COAP 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, 15 Dec 2011 06:22:22 -0000 On 11-12-14 04:30 PM, Peter Saint-Andre wrote: > As to HTTP, there's lots of practical experience in making those > deployments scale to large numbers of requests per hour/minute, > spreading the load across multiple servers, caching responses, and all > the rest. I would not assume that HTTP can't do the job. It may not be appreciated how big "large" is. I believe some of the largish DNSBLS are answering thousands of queries per second per server [+], and that's even with DNS caching. I know I've been doing DNSBL type TXT lookups at speeds of 13,000/second and more (none cacheable) sustained for 5-20 minutes at a time, and the server scarcely noticed. I think I was limited by the async query library I was using. I wouldn't rule out HTTP at that level, but it's undoubtedly a lot more expensive. [+] I keep thinking I remember comments from DNSBL operators talking about query levels one or two levels of magnitude higher than that. 600K/sec rings a bell somehow. I should go ask someone who knows. From clewis+ietf@mustelids.ca Wed Dec 14 22:39: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 E43E51F0C4A for ; Wed, 14 Dec 2011 22:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9twQVrbpxOT2 for ; Wed, 14 Dec 2011 22:39:03 -0800 (PST) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 516601F0C43 for ; Wed, 14 Dec 2011 22:39:03 -0800 (PST) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBF6d1rj001617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Dec 2011 01:39:02 -0500 Message-ID: <4EE99605.8090909@mustelids.ca> Date: Thu, 15 Dec 2011 01:39:01 -0500 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <20111214161215.13aa072e@hydrogen.roaringpenguin.com> <4EE911EF.4000701@stpeter.im> <6.2.5.6.2.20111214132118.0aaad5a8@resistor.net> <4EE91FB0.8000106@dcrocker.net> <6.2.5.6.2.20111214145652.0619e1b0@resistor.net> In-Reply-To: <6.2.5.6.2.20111214145652.0619e1b0@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Considering COAP 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, 15 Dec 2011 06:39:04 -0000 On 11-12-14 07:10 PM, SM wrote: > I used the term round-trip but it is incorrect. What we are looking at > is actually response time. Unless one can afford the expense, a classic > operation would be dealing with a response time of up to 300 ms for > example. That would make filtering unworkable. If you get cacheability > near or as part of the client, the occasional high response time becomes > acceptable. Given how current high-volume filters using reputation services are implemented/optimized now, 300ms response times shouldn't be an issue. It's probably comparable to SMTP command/response turnaround in many cases. SpamAssassin, for example, seems to have a nicely efficient asynchronous query mechanism that causes all the reputation queries to be launched at once, and each returned when they become available. More specialized filtering systems, such as qpsmtpd and many of the commercial big iron implementations are much more optimized than that. In the qpsmtpd build I did, I set the reputation query timeout to about 10 seconds (all queries were were in parallel), and left it alone. We had the occasional timeout, but the servers never had any problems coping. This was at a goodly volume - at times, 50 emails/second and higher average throughput per server. Tho, certainly, 300ms might be too high for other services you might want to protect with this. From clewis+ietf@mustelids.ca Wed Dec 14 22:57:59 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 1D0C621F84BC for ; Wed, 14 Dec 2011 22:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDg7Ac8b4oad for ; Wed, 14 Dec 2011 22:57:58 -0800 (PST) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60321F84BA for ; Wed, 14 Dec 2011 22:57:58 -0800 (PST) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBF6vavw005197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Dec 2011 01:57:42 -0500 Message-ID: <4EE99A60.3000501@mustelids.ca> Date: Thu, 15 Dec 2011 01:57:36 -0500 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] Considering COAP 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, 15 Dec 2011 06:57:59 -0000 On 11-12-14 04:16 PM, Murray S. Kucherawy wrote: > That's why we've always had the idea of supporting a lightweight mechanism that just returns a score and has all kinds of > implied context established outside the protocol between the client and the server (as DNSBLs do today), Right, thanks for reminding me. I was asked whether there were examples of existing reputation infrastructure that relied on out-of-band context for meaning, because he couldn't think of one. I replied "Lots. Most DNSBLs do exactly that". Many of the existing DNSBLs have an implied context that you have to find out from their web site. Even within Spamhaus, the recommended/supported meaning/usage of each of their component DNSBLs varies. Some DNSBLs recommend you use them in scoring, not one-strike blocking. Etc. So there's ample precedent for implied context of a reputation service. This probably isn't a good thing, because there are many times where DNSBL users use them in direct contradiction to how the DNSBL operator recommends. It can cause extreme problems when the DNSBL user naively or purposefully ignores recommended usage. I would prefer that "our" lightweight protocol whatever it may be had some sort of discovery/automatable context - reduces mistakes/misunderstandings at least. Presumably we can borrow the heavyweight stuff for that. From dhc@dcrocker.net Thu Dec 15 06:08:25 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 B4B6421F845B for ; Thu, 15 Dec 2011 06:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.625 X-Spam-Level: X-Spam-Status: No, score=-6.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj94PQwFkzkq for ; Thu, 15 Dec 2011 06:08:21 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A8B3F21F845D for ; Thu, 15 Dec 2011 06:08:21 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBFE8FUE022015 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Dec 2011 06:08:21 -0800 Message-ID: <4EE9FF49.5020307@dcrocker.net> Date: Thu, 15 Dec 2011 06:08:09 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <4EE91576.8010600@stpeter.im> <4EE9920E.9080707@mustelids.ca> In-Reply-To: <4EE9920E.9080707@mustelids.ca> 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]); Thu, 15 Dec 2011 06:08:21 -0800 (PST) Subject: Re: [domainrep] Considering COAP 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: Thu, 15 Dec 2011 14:08:25 -0000 On 12/14/2011 10:22 PM, Chris Lewis wrote: > [+] I keep thinking I remember comments from DNSBL operators talking about query > levels one or two levels of magnitude higher than that. 600K/sec rings a bell > somehow. I should go ask someone who knows. We should probably query some lists with blocklist providers to get their estimates of scaling requirement. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From dhc@dcrocker.net Thu Dec 15 06:13:58 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 8FCCA21F86C3 for ; Thu, 15 Dec 2011 06:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.624 X-Spam-Level: X-Spam-Status: No, score=-6.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UCj2yEkoJLn for ; Thu, 15 Dec 2011 06:13:54 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7130F21F85FF for ; Thu, 15 Dec 2011 06:13:54 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBFEDmKp022132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Dec 2011 06:13:53 -0800 Message-ID: <4EEA0095.2020104@dcrocker.net> Date: Thu, 15 Dec 2011 06:13:41 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <4EE7A7EF.7020904@dcrocker.net> <4EE7B1CC.1090807@stpeter.im> <4EE85E67.9090001@mnt.se> <4EE8A79A.1080808@dcrocker.net> <4EE91031.9090106@stpeter.im> <4EE99A60.3000501@mustelids.ca> In-Reply-To: <4EE99A60.3000501@mustelids.ca> 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]); Thu, 15 Dec 2011 06:13:54 -0800 (PST) Subject: Re: [domainrep] Considering COAP 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: Thu, 15 Dec 2011 14:13:58 -0000 On 12/14/2011 10:57 PM, Chris Lewis wrote: > I would prefer that "our" lightweight protocol whatever it may be had some sort > of discovery/automatable context - reduces mistakes/misunderstandings at least. > Presumably we can borrow the heavyweight stuff for that. When a protocol syntax or semantic is only distinguished by the address being used -- that is, tied to the provider.A client must know/do something different for every server it contacts and it must know what to do with each through some sort of configuration table that is set by hand. This is the essence of a significant scaling limit. The purpose of protocols is to make these things standardized. So, yeah, a separate discovery protocol or an inline "capabilities" or "features" or "tailoring" mechanism are the usual ways to accomplish that. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From johnl@iecc.com Thu Dec 15 07:43:30 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 7012B21F84A9 for ; Thu, 15 Dec 2011 07:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.892 X-Spam-Level: X-Spam-Status: No, score=-110.892 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kROPUjXpy+Ix for ; Thu, 15 Dec 2011 07:43:30 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id C9E1A21F84A3 for ; Thu, 15 Dec 2011 07:43:29 -0800 (PST) Received: (qmail 66057 invoked from network); 15 Dec 2011 15:43:27 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Dec 2011 15:43:27 -0000 Date: 15 Dec 2011 15:43:05 -0000 Message-ID: <20111215154305.86746.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org In-Reply-To: <4EE9FF49.5020307@dcrocker.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Cc: dcrocker@bbiw.net Subject: Re: [domainrep] Considering COAP 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, 15 Dec 2011 15:43:30 -0000 >We should probably query some lists with blocklist providers to get their >estimates of scaling requirement. I can ask a few of them. R's, John From johnl@iecc.com Thu Dec 15 07:52:23 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 C70B921F8AB9 for ; Thu, 15 Dec 2011 07:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.912 X-Spam-Level: X-Spam-Status: No, score=-110.912 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQYfST6OTghb for ; Thu, 15 Dec 2011 07:52:23 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [64.57.183.53]) by ietfa.amsl.com (Postfix) with ESMTP id D569F21F8A7D for ; Thu, 15 Dec 2011 07:52:22 -0800 (PST) Received: (qmail 70947 invoked from network); 15 Dec 2011 15:52:22 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 15 Dec 2011 15:52:22 -0000 Date: 15 Dec 2011 15:52:00 -0000 Message-ID: <20111215155200.86784.qmail@joyce.lan> From: "John Levine" To: domainrep@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [domainrep] COAP implementations and cart before horse 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, 15 Dec 2011 15:52:23 -0000 Having looked fairly briefly at some COAP documents, I can't help but note that it's all drafts. Is it actually done? Implemented on the kinds of computers on which people run mail software? Are there client and server libraries for Windows, Linux, and xBSD? I see libcoap which is supposed to work on Linux, but I see nothing in the FreeBSD ports library. Regardless of how wonderful it may be in theory, I don't think we'd be doing anyone any favors by specifying a protocol that people can't use on the computers where they need to use it. Seems to me that it would be a lot more productive at this point to agreee that we have placeholders for a query scheme that is relatively slow but can return large responses, and a query scheme that is fast but responses have to be smallish. Maybe they'll be HTTP and DNS, maybe something else, but we can't really say until we understand what we want them to do. R's, John From stpeter@stpeter.im Thu Dec 15 08:40: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 C1CD921F86C3 for ; Thu, 15 Dec 2011 08:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.091 X-Spam-Level: X-Spam-Status: No, score=-103.091 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBGVOE+JTDNn for ; Thu, 15 Dec 2011 08:40:48 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F16FF21F8500 for ; Thu, 15 Dec 2011 08:40:47 -0800 (PST) Received: from dhcp-64-101-72-220.cisco.com (unknown [64.101.72.220]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E64AF423D8; Thu, 15 Dec 2011 09:48:27 -0700 (MST) Message-ID: <4EEA230F.6090004@stpeter.im> Date: Thu, 15 Dec 2011 09:40:47 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: John Levine References: <20111215155200.86784.qmail@joyce.lan> In-Reply-To: <20111215155200.86784.qmail@joyce.lan> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: domainrep@ietf.org Subject: Re: [domainrep] COAP implementations and cart before horse 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, 15 Dec 2011 16:40:49 -0000 On 12/15/11 8:52 AM, John Levine wrote: > Having looked fairly briefly at some COAP documents, I can't help but > note that it's all drafts. Is it actually done? The CoAP protocol is pretty stable. There's some wrangling over MTI security mechanisms because of the constrained devices for which it was designed. > Implemented There are lots of implementations. > on the > kinds of computers on which people run mail software? We'd need to check. > Are there > client and server libraries for Windows, Linux, and xBSD? I see > libcoap which is supposed to work on Linux, but I see nothing in the > FreeBSD ports library. Something to follow up on with implementers. > Regardless of how wonderful it may be in theory, I don't think we'd > be doing anyone any favors by specifying a protocol that people > can't use on the computers where they need to use it. > > Seems to me that it would be a lot more productive at this point to > agreee that we have placeholders for a query scheme that is relatively > slow but can return large responses, and a query scheme that is fast > but responses have to be smallish. Maybe they'll be HTTP and DNS, > maybe something else, but we can't really say until we understand what > we want them to do. That seems reasonable. Peter -- Peter Saint-Andre https://stpeter.im/ From dhc@dcrocker.net Thu Dec 15 08:51:57 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 01DC121F8AD2 for ; Thu, 15 Dec 2011 08:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.623 X-Spam-Level: X-Spam-Status: No, score=-6.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZzRz6bw0UDV for ; Thu, 15 Dec 2011 08:51:55 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A18B121F8A7E for ; Thu, 15 Dec 2011 08:51:55 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBFGpnmk025720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Dec 2011 08:51:55 -0800 Message-ID: <4EEA259E.2060609@dcrocker.net> Date: Thu, 15 Dec 2011 08:51:42 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111215155200.86784.qmail@joyce.lan> <4EEA230F.6090004@stpeter.im> In-Reply-To: <4EEA230F.6090004@stpeter.im> 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]); Thu, 15 Dec 2011 08:51:55 -0800 (PST) Subject: Re: [domainrep] COAP implementations and cart before horse 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: Thu, 15 Dec 2011 16:51:57 -0000 On 12/15/2011 8:40 AM, Peter Saint-Andre wrote: >> > Seems to me that it would be a lot more productive at this point to >> > agreee that we have placeholders for a query scheme that is relatively >> > slow but can return large responses, and a query scheme that is fast >> > but responses have to be smallish. Maybe they'll be HTTP and DNS, >> > maybe something else, but we can't really say until we understand what >> > we want them to do. > That seems reasonable. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From ssilberman@constantcontact.com Thu Dec 15 11:00:56 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 C484E21F850E for ; Thu, 15 Dec 2011 11:00:56 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AZRA1J0n4zH for ; Thu, 15 Dec 2011 11:00:55 -0800 (PST) Received: from c1smtp1.constantcontact.com (c1smtp1.constantcontact.com [205.207.105.17]) by ietfa.amsl.com (Postfix) with ESMTP id AEEAF21F84FD for ; Thu, 15 Dec 2011 11:00:55 -0800 (PST) Received: from c1-exchmb01.roving.com ([192.168.221.3]) by c1-exchcas02.roving.com ([192.168.203.12]) with mapi; Thu, 15 Dec 2011 14:00:55 -0500 From: "Silberman, Sam" To: "domainrep@ietf.org" Date: Thu, 15 Dec 2011 14:03:25 -0500 Thread-Topic: [domainrep] COAP implementations and cart before horse Thread-Index: Acy7QYuzfx2j06t1SBONcWe6qdZojgAGpSFg Message-ID: References: <20111215155200.86784.qmail@joyce.lan> In-Reply-To: <20111215155200.86784.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] COAP implementations and cart before horse 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, 15 Dec 2011 19:00:56 -0000 > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On > Behalf Of John Levine > Sent: Thursday, December 15, 2011 10:52 AM > To: domainrep@ietf.org > Subject: Re: [domainrep] COAP implementations and cart before horse >=20 >=20 > Seems to me that it would be a lot more productive at this point to > agreee that we have placeholders for a query scheme that is relatively > slow but can return large responses, and a query scheme that is fast > but responses have to be smallish. Maybe they'll be HTTP and DNS, > maybe something else, but we can't really say until we understand what > we want them to do. >=20 +1 -Sam From tony@att.com Thu Dec 15 12:14: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 67CB521F849E for ; Thu, 15 Dec 2011 12:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.044 X-Spam-Level: X-Spam-Status: No, score=-106.044 tagged_above=-999 required=5 tests=[AWL=0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wr2mNEFPdfTA for ; Thu, 15 Dec 2011 12:14:39 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id BE83421F8483 for ; Thu, 15 Dec 2011 12:14:38 -0800 (PST) X-Env-Sender: tony@att.com X-Msg-Ref: server-16.tower-119.messagelabs.com!1323980076!6005349!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1270 invoked from network); 15 Dec 2011 20:14:37 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-16.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Dec 2011 20:14:37 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBFKF4wC011228 for ; Thu, 15 Dec 2011 15:15:05 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id pBFKF1cw011133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 15 Dec 2011 15:15:01 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 15 Dec 2011 15:14:23 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pBFKENFj010164 for ; Thu, 15 Dec 2011 15:14:23 -0500 Received: from mailgw1.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id pBFKEFKJ009634 for ; Thu, 15 Dec 2011 15:14:15 -0500 Received: from [135.91.110.247] (njcdtl03th1395.itservices.sbc.com[135.91.110.247]) by maillennium.att.com (mailgw1) with ESMTP id <20111215201252gw100e4lvte> (Authid: tony); Thu, 15 Dec 2011 20:12:52 +0000 X-Originating-IP: [135.91.110.247] Message-ID: <4EEA5516.3040009@att.com> Date: Thu, 15 Dec 2011 15:14:14 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111215155200.86784.qmail@joyce.lan> In-Reply-To: <20111215155200.86784.qmail@joyce.lan> Content-Type: multipart/alternative; boundary="------------000107010605070009020607" X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: Re: [domainrep] COAP implementations and cart before horse 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, 15 Dec 2011 20:14:39 -0000 This is a multi-part message in MIME format. --------------000107010605070009020607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 12/15/2011 10:52 AM, John Levine wrote: > Seems to me that it would be a lot more productive at this point to > agreee that we have placeholders for a query scheme that is relatively > slow but can return large responses, and a query scheme that is fast > but responses have to be smallish. Maybe they'll be HTTP and DNS, > maybe something else, but we can't really say until we understand what > we want them to do. seems reasonable to just mark where a stake in the ground needs to go and not worry about the color or length of the stake for now. +1 Tony Hansen --------------000107010605070009020607 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 12/15/2011 10:52 AM, John Levine wrote: 
Seems to me that it would be a lot more productive at this point to
agreee that we have placeholders for a query scheme that is relatively
slow but can return large responses, and a query scheme that is fast
but responses have to be smallish.  Maybe they'll be HTTP and DNS,
maybe something else, but we can't really say until we understand what
we want them to do.

seems reasonable to just mark where a stake in the ground needs to go and not worry about the color or length of the stake for now.

+1

    Tony Hansen
--------------000107010605070009020607-- From internet-drafts@ietf.org Fri Dec 16 11:18: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 5B96C21F84DB; Fri, 16 Dec 2011 11:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykJCWTOaSdDH; Fri, 16 Dec 2011 11:18:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7AFC21F8492; Fri, 16 Dec 2011 11:18:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20111216191835.2097.18742.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2011 11:18:35 -0800 Cc: domainrep@ietf.org Subject: [domainrep] I-D Action: draft-ietf-repute-email-identifiers-01.txt 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, 16 Dec 2011 19:18:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Reputation Services Working Group of = the IETF. Title : A Reputation Vocabulary for Email Identifiers Author(s) : Nathaniel Borenstein Murray S. Kucherawy Filename : draft-ietf-repute-email-identifiers-01.txt Pages : 7 Date : 2011-12-16 This document defines a vocabulary for describing email identifiers (typically authors or signers) with the application/reputon media type. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.= txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.t= xt From msk@cloudmark.com Fri Dec 16 11:25:19 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 8ED6321F86A6 for ; Fri, 16 Dec 2011 11:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Je1AZ6i775UK for ; Fri, 16 Dec 2011 11:25:19 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id 18AEB21F86A1 for ; Fri, 16 Dec 2011 11:25:18 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 16 Dec 2011 11:25:17 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Fri, 16 Dec 2011 11:25:18 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Fri, 16 Dec 2011 11:25:16 -0800 Thread-Topic: I-D Action: draft-ietf-repute-email-identifiers-01.txt Thread-Index: Acy8J4ltcTwxKRgHQnuRMA/l+ZpImAAAGJJA Message-ID: References: <20111216191835.2097.18742.idtracker@ietfa.amsl.com> In-Reply-To: <20111216191835.2097.18742.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-repute-email-identifiers-01.txt 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, 16 Dec 2011 19:25:19 -0000 > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Friday, December 16, 2011 11:19 AM > To: i-d-announce@ietf.org > Cc: domainrep@ietf.org > Subject: I-D Action: draft-ietf-repute-email-identifiers-01.txt >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Reputation Services > Working Group of the IETF. >=20 > Title : A Reputation Vocabulary for Email Identifiers > Author(s) : Nathaniel Borenstein > Murray S. Kucherawy > Filename : draft-ietf-repute-email-identifiers-01.txt > Pages : 7 > Date : 2011-12-16 >=20 > This document defines a vocabulary for describing email identifiers > (typically authors or signers) with the application/reputon media > type. You can look at the diffs via the datatracker, but basically this takes int= o account some of the feedback about the assertions. For example, things l= ike "SENDS-SPAM" makes some impossible claims in the DKIM context because D= KIM doesn't make any assertions about who actually sent the message. So th= is has been softened to just "SPAM", and the description means "is associat= ed with spam". It also uses the preferred language of "identifiers" in place of "identitie= s", and improves the definition of what SPF provides. Updates to the media-type and query-http documents are in the hopper, which= are mostly reorganization of information per on-list suggestions. Those s= hould come out next week or the week after. -MSK From dotis@mail-abuse.org Fri Dec 16 12:17: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 A2C9221F8B05 for ; Fri, 16 Dec 2011 12:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BkUHZ7jzAlJ for ; Fri, 16 Dec 2011 12:17:47 -0800 (PST) Received: from mailserv.mail-abuse.org (mailserv.mail-abuse.org [150.70.98.118]) by ietfa.amsl.com (Postfix) with ESMTP id D6FCC21F8B04 for ; Fri, 16 Dec 2011 12:17:47 -0800 (PST) Received: from US-DOUGO-MAC.local (sjdcluxgateway2.sdi.trendnet.org [10.31.37.9]) by mailserv.mail-abuse.org (Postfix) with ESMTPSA id 9637F17404E2 for ; Fri, 16 Dec 2011 20:17:47 +0000 (UTC) Message-ID: <4EEBA76A.2010301@mail-abuse.org> Date: Fri, 16 Dec 2011 12:17:46 -0800 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: domainrep@ietf.org References: <20111216191835.2097.18742.idtracker@ietfa.amsl.com> In-Reply-To: <20111216191835.2097.18742.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [domainrep] I-D Action: draft-ietf-repute-email-identifiers-01.txt 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, 16 Dec 2011 20:17:48 -0000 On 12/16/11 11:18 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Reputation Services Working Group of the IETF. > > Title : A Reputation Vocabulary for Email Identifiers > Author(s) : Nathaniel Borenstein > Murray S. Kucherawy > Filename : draft-ietf-repute-email-identifiers-01.txt > Pages : 7 > Date : 2011-12-16 > > This document defines a vocabulary for describing email identifiers > (typically authors or signers) with the application/reputon media > type. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-repute-email-identifiers-01.txt In the Security Consideration section there should be a list of exclusions on use of identifiers used in conjunction with related mechanisms that fail to authenticate the claimed actions of Malware, Spam, or Invalid Recipients. For example: DKIM must be limited to the action of Malware only. DKIM does not authenticate the domain accountable for Invalid Recipients or Spam. DKIM signature validity is unrelated to the domain sending messages and/or asserting recipient addresses. DKIM signature validity is also unrelated to messages containing misleading pre-pended header fields. The misapplication of reputation would represent a disruptive protocol enforcement mechanism that will punish domains that failed to anticipate invalid formats specifically permitted by SMTP that should have been proactively anticipated by the DKIM protocol itself. SPF in conjunction with RFC5321.MAILFROM or RFC5321.FROM does not confirm which possible identifier was intended to reference SPF authorizations, and whether these identifiers uniquely relate to SPF referenced domains. Such uncertainty means holding SPF domains accountable for any of the listed actions may be open to exploitation. Only the RFC5321.Helo in conjunction with SPF offers confirmation of the referenced domain's involvement. A workable and fair reputation system must ensure providers are able to defend their reputation. There is no excuse for not ensuring accountability for the purported action. -Doug From sm@resistor.net Sat Dec 17 00:23: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 14CA821F84A5 for ; Sat, 17 Dec 2011 00:23:12 -0800 (PST) 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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxmWpwedCFhE for ; Sat, 17 Dec 2011 00:23:10 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2121F8457 for ; Sat, 17 Dec 2011 00:23:09 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pBH8MhKH016180 for ; Sat, 17 Dec 2011 00:23:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1324110185; bh=ExSgMzasfWiytLr5gmBE/qhTdZYpVtls6Q/9ROWoAwI=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=RsueN/26BYa69W95nUdTNtcTQKpVkxGCZl7GFASDD3t1QV2fG3/Jj7KzBUCuG4GR+ LjU85iVktCKNTdJwipnGOjV0/997X3JGQQ1k3Ox803AOfPkrixD73XaOjXe/28byVI eD5Bn0qAG/7Y2bcqGliX9+PcOy9Aau5hLs/81+Y8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1324110185; bh=ExSgMzasfWiytLr5gmBE/qhTdZYpVtls6Q/9ROWoAwI=; h=Message-Id:Date:To:From:Subject:Mime-Version:Content-Type:Cc; b=uuv8RZwDqY3m4k0U4m6z/HLykxx6ajd12kWMqProDtaDX2M6gNy2ucfDwuZ4RU4to HL/IgNj8kB5KmoWQwbsUASVCHQ3TCs6JlPz/qAcdbXYVkOKwVyAh4wovDfFRhDqxkK 3PpJ66VUQBVq3TzaFX/cJ2EJfIWzkT/bF6QkLP0Q= Message-Id: <6.2.5.6.2.20111216231450.09c38530@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 17 Dec 2011 00:04:44 -0800 To: domainrep@ietf.org From: SM Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [domainrep] Comments on draft-ietf-repute-email-identifiers-01 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: Sat, 17 Dec 2011 08:23:12 -0000 I have a few comments on draft-ietf-repute-email-identifiers-01. BTW, some of the suggested text requires fine-tuning. In the Abstract Section: "This document defines a vocabulary for describing email identifiers (typically authors or signers) with the application/reputon media type." I suggest copying some text from the Introduction Section: This document defines a vocabulary for describing assertions a reputation service provider can make about email identifiers. In Section 1: 'This memo defines a "vocabulary" for describing reputation of an email identifier. A "vocabulary" in this context is defined in [RFCxxxx]' If the draft defines a vocabulary, the last part of the above does not make sense. I suggest reusing material from the Feedback Report Type Values registry instead of the terms in Section 3.1. Abuse: The email identifier is associated with unsolicited email or some other kind of email abuse Fraud: The email identifier is associated with some kind of fraud or phishing activity Not-spam: The email identifier is associated with an indication about messages not considered to be spam Virus: The email identifier is associated with viruses. Invalid-Recipients: The email identifier is associated with delivery attempts to nonexistent recipients Although I do not see how the last one fits in, I left it in. In the above text, emphasis is on association with an email identifier. Section 3.2 mentions that the "email-id" reputation application recognizes the following OPTIONAL extensions to the basic vocabulary defined in [RFCxxxx]. The list looks more like email identifiers instead of extensions to the vocabulary. If so, swap this section with the previous one and provide a description of email identifiers. In Section 3.2: "A reply that does not contain the IDENTITY or SOURCES extensions is making a non-specific statement about how the reputation returned was developed. A client may use or ignore such a reply at its discretion." I suggest moving this to the protocol document. For now, leave it in and add a note. In Section 4, there is a typo for "registration". The RFC 2119 and RFC 5598 references should be normative. Regards, -sm From dhc@dcrocker.net Wed Dec 21 16:06:18 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 EE0C011E80D0 for ; Wed, 21 Dec 2011 16:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN6R6X9MKENc for ; Wed, 21 Dec 2011 16:06:18 -0800 (PST) Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABC311E8096 for ; Wed, 21 Dec 2011 16:06:18 -0800 (PST) Received: from [192.168.1.11] (adsl-67-127-55-53.dsl.pltn13.pacbell.net [67.127.55.53]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id pBM069Fw019531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Dec 2011 16:06:16 -0800 Message-ID: <4EF27462.3080206@dcrocker.net> Date: Wed, 21 Dec 2011 16:05:54 -0800 From: Dave CROCKER Organization: Brandenburg InternetWorking User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "domainrep@ietf.org" References: <20111221165546.E2A761F0C4C@ietfa.amsl.com> In-Reply-To: <20111221165546.E2A761F0C4C@ietfa.amsl.com> X-Forwarded-Message-Id: <20111221165546.E2A761F0C4C@ietfa.amsl.com> 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, 21 Dec 2011 16:06:17 -0800 (PST) Subject: [domainrep] Fwd: IETF 83 - Registration Now Open 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: Thu, 22 Dec 2011 00:06:19 -0000 -------- Original Message -------- Subject: IETF 83 - Registration Now Open Date: Wed, 21 Dec 2011 08:55:46 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: wgchairs@ietf.org, irsg@irtf.org 83rd IETF Meeting Paris, France March 25-30, 2012 Host: TBD Meeting venue: Le Palais des Congres de Paris http://www.viparis.com/Viparis/exhibition-paris/site/Palais-Congres-Paris-Paris/en/4 Register online at: http://www.ietf.org/meetings/83/ 1. Registration 2. Visas & Letters of Invitation 3. Accommodations: IMPORTANT: Please read hotel cancellation policies 4. Companion Program 1. Registration A. Early-Bird Registration - USD 650.00 Pay by Friday, 16 March 2012 1700 PT (UTC -7) B. After Early-Bird cutoff - USD 800.00 C. Full-time Student Registrations - USD 150.00 (with proper ID) D. One Day Pass Registration - USD 350.00 E. Registration Cancellation Cut-off for registration cancellation is Monday, 19 March 2012 at 1700 PT (UTC -7). Cancellations are subject to a 10% (ten percent) cancellation fee if requested by that date and time. F. Online Registration and Payment ends Friday, 23 March 2012, 1700 local Paris time. G. On-site Registration starting Sunday, 25 March 2012 at 1100 local Paris time. 2. Visas & Letters of Invitation: Information on Visiting France, please visit: http://www.consulfrance-sanfrancisco.org/spip.php?rubrique201 After you complete the registration process, can request an electronic IETF Letter of Invitation. You may also request one at a later time by following the link provided in the confirmation email. Please note that the IETF Letter of Invitation may not be sufficient for obtaining a visa to come to France. We are working with local representatives to secure the appropriate letters for those who need them, and will have more information after January 1, 2012. 3. Accommodations The IETF is holding blocks of guest rooms at 2 hotels in Paris: the Hotel Concorde La Fayette (Headquarter Hotel - connected to meeting venue) and the Le Meridien Etoile (directly across the street from the meeting venue) Room rates include one complimentary daily buffet breakfast and complimentary in-room high-speed Internet access. All service fees and VAT are included in guest room rates. NOTE: Continental Breakfast will NOT be served at the meeting venue. Reservations Cut off Date: 23 January 2012 at the Le Meridien 09 March 2012 at Hotel Concorde ****Cancellation Policy at Le Meridien**** Guest Cancellation: - There is no charge if room is cancelled prior to March 2012 - There is a one night charge for cancellations made between 09 March and 23 March 2012 - If the room is cancelled from 23 March 2012 or if the guest is a "no-show" then the amount of the entire stay will be charged onto the guest's credit card. Early Departure Fee: Early departure will be charged for the duration of the stay as reserved if changes are made after March 23, 2012. Guest Substitution: Guest name substitute may be made by contacting Corinne Vissenberg . ****Cancellation Policy at Hotel Concorde*** Reservation Deposit and Cancellations: - Guaranteed reservations will be held until the night of the arrival date. - Guests will be be charged 1 night's stay and tax at the time the reservation is made. - 15 days prior to scheduled arrival the guest's credit card shall be charged for an additional 2 nights stay and tax which is non-refundable. Guest Cancellation: - Guest will forfeit the non-refundable deposit paid as of the date of the cancellation. Guest Substitution: - Guests may substitute names for reserved rooms without penalty. Early Departure Fee: - In the event of early departure, the guest will be charged for the remainder of their stay. Should the room nights be re-sold, the guest will be refunded for the resold room nights. For additional information on rates and policies, please visit: http://www.ietf.org/meeting/83/hotel.html 4. Companion Program If you are traveling with a friend or family member over 18 years of age you can register them for the IETF Companion Program for only USD 15.00 Benefits include: - A special welcome reception for companions from 1630-1730 on Sunday, 25 March - Ability to attend the official Welcome Reception from 1700-1900 on Sunday, 25 March - A distinctive meeting badge that grants access to the venue (not to be used to attend working sessions) - Participation in a separate companion email list if you choose to help communicate and make plans with other IETF Companions. You can register your companion at any time via the IETF website or onsite at the meeting. To join the 83 companions mailing list see: https://www.ietf.org/mailman/listinfo/83companions Only 94 days until the Paris IETF! _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce -- Dave Crocker Brandenburg InternetWorking bbiw.net From msk@cloudmark.com Sat Dec 24 23:32:01 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 C0F6E21F841C for ; Sat, 24 Dec 2011 23:32:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDj5biaR2Ijh for ; Sat, 24 Dec 2011 23:32:01 -0800 (PST) Received: from ht1-outbound.cloudmark.com (ht1-outbound.cloudmark.com [72.5.239.25]) by ietfa.amsl.com (Postfix) with ESMTP id A488821F8477 for ; Sat, 24 Dec 2011 23:31:56 -0800 (PST) Received: from malice.corp.cloudmark.com (172.22.10.71) by EXCH-HTCAS901.corp.cloudmark.com (172.22.10.73) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 24 Dec 2011 23:31:53 -0800 Received: from EXCH-C2.corp.cloudmark.com ([172.22.1.74]) by malice.corp.cloudmark.com ([172.22.10.71]) with mapi; Sat, 24 Dec 2011 23:31:56 -0800 From: "Murray S. Kucherawy" To: "domainrep@ietf.org" Date: Sat, 24 Dec 2011 23:32:00 -0800 Thread-Topic: [domainrep] Comments on draft-ietf-repute-email-identifiers-01 Thread-Index: Acy8lSYd42WjOYVcRCSrFhlqkLRD3AGQNcrA Message-ID: References: <6.2.5.6.2.20111216231450.09c38530@elandnews.com> In-Reply-To: <6.2.5.6.2.20111216231450.09c38530@elandnews.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] Comments on draft-ietf-repute-email-identifiers-01 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, 25 Dec 2011 07:32:01 -0000 Hi SM, > -----Original Message----- > From: domainrep-bounces@ietf.org [mailto:domainrep-bounces@ietf.org] On B= ehalf Of SM > Sent: Saturday, December 17, 2011 12:05 AM > To: domainrep@ietf.org > Subject: [domainrep] Comments on draft-ietf-repute-email-identifiers-01 >=20 > In the Abstract Section: >=20 > "This document defines a vocabulary for describing email identifiers > (typically authors or signers) with the application/reputon media > type." >=20 > I suggest copying some text from the Introduction Section: >=20 > This document defines a vocabulary for describing assertions a > reputation service provider can make about email identifiers. Works for me, except I think it's appropriate to mention the media type bec= ause otherwise someone reading this abstract has no context. > In Section 1: >=20 > 'This memo defines a "vocabulary" for describing reputation of an > email identifier. A "vocabulary" in this context is defined in > [RFCxxxx]' >=20 > If the draft defines a vocabulary, the last part of the above does not > make sense. I changed it to "This memo specifies a vocabulary for describing...", remov= ing the quotes and changing "defines" to "specifies", to make it clear the = other document is the foundational one. > I suggest reusing material from the Feedback Report Type Values > registry instead of the terms in Section 3.1. >=20 > Abuse: The email identifier is associated with unsolicited email > or some other kind of email abuse This seems too general to be a useful assertion. > Fraud: The email identifier is associated with some kind of fraud > or phishing activity Modified the FRAUD definition to say, 'such as "phishing"'. I'll probably = be challenged to define that or refer to a definition of it; I'll try to fi= nd one. > Not-spam: The email identifier is associated with an indication about > messages not considered to be spam Wouldn't you just assert the same thing here as one minus the SPAM score? > Virus: The email identifier is associated with viruses. This also seems a little too general. I prefer the current MALWARE definit= ion. > Section 3.2 mentions that the "email-id" reputation application > recognizes the following OPTIONAL extensions to the basic vocabulary > defined in [RFCxxxx]. The list looks more like email identifiers > instead of extensions to the vocabulary. If so, swap this section with > the previous one and provide a description of email identifiers. It allows the reputation provider to make a statement about how its score s= hould be applied. For example, if you don't specify the context somehow as= part of the query (or implicitly based on who you're asking), the provider= could tell you "this is the SPAM score for example.com as long as you mean= to use it to evaluate DKIM signature domains". The email-id vocabulary is a set of keywords and extensions to the base voc= abulary defined in the "model" document. So I believe it makes sense to pu= t it where it is. > In Section 3.2: >=20 > "A reply that does not contain the IDENTITY or SOURCES extensions is > making a non-specific statement about how the reputation returned was > developed. A client may use or ignore such a reply at its > discretion." >=20 > I suggest moving this to the protocol document. For now, leave it in > and add a note. IDENTITY and SOURCES are email-id extensions, so moving them to either the = model or media-type document won't make sense. However, if we feel they ou= ght to be made mandatory parts of all vocabularies, then that would make se= nse. > In Section 4, there is a typo for "registration". >=20 > The RFC 2119 and RFC 5598 references should be normative. I agree with 2119, but do you really have to read 5598 to implement this? Thanks, -MSK From clewis+ietf@mustelids.ca Fri Dec 30 17:47:40 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 E2D8121F853B for ; Fri, 30 Dec 2011 17:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.089 X-Spam-Level: * X-Spam-Status: No, score=1.089 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXNHAj+SFPo4 for ; Fri, 30 Dec 2011 17:47:40 -0800 (PST) Received: from mail.mustelids.ca (unknown [174.35.130.2]) by ietfa.amsl.com (Postfix) with ESMTP id C462C21F853A for ; Fri, 30 Dec 2011 17:47:39 -0800 (PST) Received: from [192.168.0.8] (otter.mustelids.ca [192.168.0.8]) (authenticated bits=0) by mail.mustelids.ca (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pBV1lPcf012732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Dec 2011 20:47:28 -0500 Message-ID: <4EFE69AD.8040707@mustelids.ca> Date: Fri, 30 Dec 2011 20:47:25 -0500 From: Chris Lewis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: domainrep@ietf.org Content-Type: multipart/mixed; boundary="------------090307050202040205060309" Subject: [domainrep] Reputation use cases. 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: Sat, 31 Dec 2011 01:47:41 -0000 This is a multi-part message in MIME format. --------------090307050202040205060309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [!Chair] I threw the attachment together to show what current spam filtering technology uses in the "reputation area". It's hoped that it may provide a background and focal point for discussions on identifiers, how the results may get used, and identifying the sorts of flexibility that a reputation query protocol may need. I suspect it may be turned into an informational/working document of some sort, but at this point I thought a simple brain-dump in text format would serve for the moment. --------------090307050202040205060309 Content-Type: text/plain; name="REPUTEUseCases.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="REPUTEUseCases.txt" EMail Reputation Use Cases This is not meant to be 100% exhaustive. It lists a variety of "reputation-ish" methodologies that are used in many email environments for spam and malware filtering. If I've missed anything substantial, please let me know. By "reputation-ish", I'm referring to filtering technologies that work based on "who or what sent it, or on whose behalf". Where the "who" may well be entirely unproven. This is opposed to filtering methodologies that work on a more generalized view of the email (such as content-based). I'm specifically going to leave out site-specific manual filtering of individual identifiers. Focus is on the medium to large installation, where these measures are implemented at the server level. Though, this description applies to anyone using SpamAssassin or similar, large or small. While many of the methods return simple "yes" or "no" (or "good"/"bad") answers, this does not require that the analysis results in the email being thrown away after a single "bad" answer. Indeed, SpamAssassin (one of the most popular packages, and inspirer of many others) asks a myriad of questions that essentially have only yes/no answers, each answer is given a score (which can be either negative or positive), and only when the aggregate score exceeds a set threshold is the email affected. Since SpamAssassin is quite well known and performs a lot of these tests, it's a good package to take instruction from. While many medium to larger installations do not use SpamAssassin per-se, the individual techniques SpamAssassin uses are quite common. There's several purposes to this document: - show the different identifiers used. - show that the answers you get from these reputation-ish things aren't necessarily "good/bad" answers, sometimes simply external information about the identifier, and how to use it is up to the consumer of the information. - show that even unauthenticated information can be useful - show that flexibility, such as being able to "wildcard" answers is useful. - Show that filtering systems may well integrate many "reputation-ish" results together before coming up with an answer. I'm not going to say much about SPF/SenderID or DKIM because that seems already adequately understood within the WG context. Remember they are authentication methods. A successful SPF or DKIM verification does not necessarily imply anything about whether the email is desirable or not. This document outlines methods where you're querying the "desirability" or information needed to determine "desirability". All of these identifiers are used within existing list technology (including DNS-based). But, depending on the installation, they could also be local configuration files, databases, or custom protocols. Note well: this document describes what current systems do in this area. Any discussion of the rightness or wrongness of individual techniques is clearly out-of-scope. 1) The first, and most obvious, reputation-ish technique is to look up the connecting IP address in a database accessed in some fashion. While some of these databases (eg: locally generated manual ones) are usually general purpose catchalls, most of the available databases are derived from only a few heuristics. Such as: - Known/deliberate spam/malware sender - Provider asserts there shouldn't be mail servers at this IP - Host infected with email sending malware - The ratio of spam/ham from this IP is unacceptably high - This is a "good/well managed" IP (a "whitelist") Some databases are aggregations of single-heuristic databases. Some databases contain ranges, some single IP addresses. What this tends to mean is that usually more than one of these databases is queried per email. In the SpamAssassin case, it's well over a dozen - each answer scored independently. 2) Some of the connecting-IP based databases don't say something inherently bad or good about an IP. Instead, they give other information. Such as, "this IP is in country XX" or "The ASN for this IP is xxx". These can come in useful both for scoring, or absolute blocking (eg: a small site deciding that there's a vanishingly small possibility that any email coming from AS is legitimate/wanted). Such databases could also contain spam/ham ratios, domain age, registrar name, and so on. [I've built a DNS-based one that returns a TXT record that has the allocation CIDR, ASN, domain name, abuse contact address, country and state. I use this for logging/metrics, but could also use it for filtering.] 3) The reverse DNS value is checked. This can range from the simplistic "don't accept email from IPs with '.dhcp.' in their rDNS") to the complex. For an example of the latter, consider "Enemies List" (aka EL) which has 10's of thousands of patterns that try to derive attributes from the string such as, "broadband", "static", "server", "multi-hosting environment" etc. The result can be scored, or used in unconditional blocking heuristics. EL is relatively little known, but it works surprisingly well if you base your decisioning correctly. EL is commonly implemented as a local database, but can support RHSBL-like DNS queries. Reverse DNS values are sometimes checked against domain- or hostname-based databases (eg: URIBLs and RHSBLs). Much like IP-based databases, many of these databases are single-heuristic, aggregations of single-heuristic, or purely informational. One example of "informational" is "is this a recent registration?". But others are possible, such as lookups to see who the registrar is, spam/ham ratios, is it an anonymous registration etc. The effect of a listing can be positive or negative. SpamAssassin has various simplistic rDNS rules, and now has EL support. I'm not sure whether it does DNS-based rDNS lookups per-se. 4) The HELO is checked, potentially much the same way as reverse DNS, including EL-like methods. Special rules like "don't helo as my name or IP", "don't helo as someone it's clear you're not", "at least give me a RFC5321-legal HELO" are also common. HELOS are also checked against domain- or hostname-based lookups. SpamAssassin has various hardcoded HELO checks too. 5) The MAIL FROM is checked, usually either domain- or hostname-based checking similarly to HELO. SpamAssassin also has, I believe, queries to various informational DNSBLs, and can look them up in more classical RHSBLs or URIBLs. 6) SPF/Senderid analysis can potentially use any of the previous identifiers (connecting IP, HELO, MAIL FROM especially). [SpamAssassin does support SPF as well as DKIM. But without being able to acquire reputation for the identifiers, they're of little use.] 7) Headers identifying the sender are often treated to the similar testing as MAIL FROMs. 8) Received headers are often parsed for previous hand-off IPs and hostnames. FYI: this is a hazardous practise with some databases, especially given the propensity of some spamware to generate fake Received headers, but discussing that is out of scope for the WG, other than to point out that even SpamAssassin had to make some changes in this area. 9) Sometimes other headers are parsed if present. For example, X-Originating-IP is sometimes usefully looked up in some databases or hard-coded rules. 10) Email payloads are often scanned for useful identifiers. The most prevalent is the derivation of hostnames and "registry level" domains to do domain-based lookups via RHSBL- or URIBL-like databases. (aka "SURBL lookups" etc) IP-based URLs are often looked up too (via URIBL-like databases, or connection-IP-based DNSBLs). SpamAssassin has more than a dozen URL derived lookups by default. SpamAssassin's SURBL lookups are constrained to do only N distinct domain lookups in URLs. SUMMARY: The following "identifiers" are frequently used in reputation-ish queries: connecting IP, reverse DNS, HELO value, MAIL FROM (domain at least), sender headers, and URL hostnames. Domain names are potentially queried at both the full hostname or "registry level" domain. The return values can mean "good" or "bad", but can also simply be other information to be analyzed as desired. Or even just logged. The return values are often scored, rather than "single strike". Success (as in, the filter blocks what it should, and doesn't block what it shouldn't) relies on the information provider providing what they say they are, and the consumer of the information applying it intelligently. This extends even to when the identifier isn't "authenticated" in any significant fashion. If a particular identifier is known to always be "bad", anything spoofing that particular identifier is a-priori "bad" too. The same is NOT true in the reverse obviously. Both in IP addresses and in domain names, much of the use implies something analogous to wildcarding. Eg: databases containing ranges of IPs, or reputation providers trying to assert something about a domain and all subdomains. The above paragraph generally implies that the provider of the information has to be able to do pattern matching (eg: range checking or domain wildcarding). Which means that you can't hide the identifier from the provider, otherwise, the provider can't decompose it to coarser grain entries. --------------090307050202040205060309--