From rucus-bounces@ietf.org Tue Apr 1 12:57:22 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2102B28C3BD; Tue, 1 Apr 2008 12:57:22 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 285DD28C3B2 for ; Tue, 1 Apr 2008 12:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=0.801, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ItttJTXtcz4 for ; Tue, 1 Apr 2008 12:57:16 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 527EF28C3BD for ; Tue, 1 Apr 2008 12:57:15 -0700 (PDT) Received: (qmail invoked by alias); 01 Apr 2008 19:57:13 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp055) with SMTP; 01 Apr 2008 21:57:13 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+f239JDN+fO7tvle2rr2Lo31unFRsWSZ3dnZgQ8O jx9PRuCuy8mNLe Message-ID: <47F29396.9070503@gmx.net> Date: Tue, 01 Apr 2008 22:57:10 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: rucus BoF X-Y-GMX-Trusted: 0 Subject: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org A little time passed after the IETF meeting and now we need to go back to work. We now need to determine the expected outcome of the Exploratory Group (otherwise it cannot get chartered). My impression from the discussion at the IETF meeting was that we would want to determine what mechanisms (that got proposed so far) are useful enough for most of the folks in the group to later work on. To make it a bit more "challenging" we should limit the number of items we want to standardize to a small number. Let's say "3". Is that a useful expected outcome? Decide on 3 solution approaches that we would like to standardize. We would obviously want to describe on what "properties" we get when we have these three mechanisms. Ciao Hannes _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Apr 1 16:06:05 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46153A6A9D; Tue, 1 Apr 2008 16:06:05 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86283A6841 for ; Tue, 1 Apr 2008 16:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.389 X-Spam-Level: X-Spam-Status: No, score=-4.389 tagged_above=-999 required=5 tests=[AWL=2.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qS53AQydY+S for ; Tue, 1 Apr 2008 16:06:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 008113A6E4A for ; Tue, 1 Apr 2008 16:05:25 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2008 16:05:25 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m31N5PAo011269; Tue, 1 Apr 2008 16:05:25 -0700 Received: from dwingwxp01 (rtp-vpn5-473.cisco.com [10.82.233.218]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m31N5NMI018653; Tue, 1 Apr 2008 23:05:24 GMT From: "Dan Wing" To: "'Hannes Tschofenig'" , "'rucus BoF'" References: <47F29396.9070503@gmx.net> Date: Tue, 1 Apr 2008 16:05:23 -0700 Message-ID: <1a4601c8944c$de7a9520$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47F29396.9070503@gmx.net> X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciUMp393eShazZdSOeVL3EAiNybfwAGOxSg DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2392; t=1207091125; x=1207955125; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Rucus]=20Next=20Steps=20towards=20the= 20EG |Sender:=20; bh=npa6iMJJz/RIxJcgCToGbIdZsk2YWqxfinE20Uj4yOU=; b=CmynUMWsGLtIfNNIWcCcF5wQ+1VcVMbL8n8vtv1Zp7nqEENmdKER5Q4qEn KQm1nhJvGmHu6hKVtBxhq8EtyZNvQkcCd2bwxoRD+yoo8yEzuUplQrjn/20U Yz7EcOlfPl; Authentication-Results: sj-dkim-4; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Jonathan's presentation at the Philadelphia RUCUS meeting, "RFC 5039 Overview" , had a slide that showed each RFC5039 solution in red, yellow, and green. The intent, as I understood it, is that red meant solutions that were difficult to implement or were not likely to be successful, green is for solutions that should be relatively easy to implement and should be relatively successful, and yellow is between green and red. Red solutions: * Content Filtering * Address Obfuscation * Computational Puzzles * Payments at Risk Yellow solutions: * Black Lists * Reputation * Limited Use Addresses * Turing Tests * Legal Action Green solutions: * White Lists * Consent * Circles of Trust * Centralized Providers and text to the right on Jonathan's slide said "Strong Identity a Key For Many of these!". I propose that RUCUS concentrate on the first three listed as green, namely: * White Lists * Consent * Circles of Trust I don't believe there is much to be standardized with the last green solution, Centralized Providers. -d > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Tuesday, April 01, 2008 12:57 PM > To: rucus BoF > Subject: [Rucus] Next Steps towards the EG > > A little time passed after the IETF meeting and now we need > to go back > to work. > > We now need to determine the expected outcome of the > Exploratory Group > (otherwise it cannot get chartered). > > My impression from the discussion at the IETF meeting was > that we would > want to determine what mechanisms (that got proposed so far) > are useful > enough for most of the folks in the group to later work on. > To make it a > bit more "challenging" we should limit the number of items we want to > standardize to a small number. Let's say "3". > > Is that a useful expected outcome? Decide on 3 solution > approaches that > we would like to standardize. > We would obviously want to describe on what "properties" we > get when we > have these three mechanisms. > > Ciao > Hannes > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Apr 1 16:44:33 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3493A6E90; Tue, 1 Apr 2008 16:44:33 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6D1D28C292 for ; Tue, 1 Apr 2008 16:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7tzkdqMBHkI for ; Tue, 1 Apr 2008 16:44:32 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id C80DD28C101 for ; Tue, 1 Apr 2008 16:44:31 -0700 (PDT) Received: from [192.168.0.57] (pool-71-250-66-107.nwrknj.east.verizon.net [71.250.66.107]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m31NiOdX004926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Apr 2008 19:44:25 -0400 (EDT) Message-Id: <47F9FF99-40EA-4B13-8C3F-8994B3DBEF0F@cs.columbia.edu> From: Henning Schulzrinne To: Dan Wing In-Reply-To: <1a4601c8944c$de7a9520$c5f0200a@cisco.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 1 Apr 2008 19:44:25 -0400 References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: 'rucus BoF' Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes should speak for himself, but I thought we were talking a bit more general, rather than specific spam prevention solutions. For example, one tool that's been discussed repeatedly is the marking of calls and the various call treatment options. I don't think it's particularly productive to go through all the spam techniques. On Apr 1, 2008, at 7:05 PM, Dan Wing wrote: > Jonathan's presentation at the Philadelphia RUCUS meeting, "RFC 5039 > Overview" > , had a > slide that > showed each RFC5039 solution in red, yellow, and green. The intent, > as I > understood it, is that red meant solutions that were difficult to > implement or > were not likely to be successful, green is for solutions that should > be > relatively easy to implement and should be relatively successful, > and yellow > is between green and red. > > Red solutions: > * Content Filtering > * Address Obfuscation > * Computational Puzzles > * Payments at Risk > > Yellow solutions: > * Black Lists > * Reputation > * Limited Use Addresses > * Turing Tests > * Legal Action > > Green solutions: > * White Lists > * Consent > * Circles of Trust > * Centralized Providers > > and text to the right on Jonathan's slide said "Strong Identity a > Key For Many > of these!". > > > > I propose that RUCUS concentrate on the first three listed as green, > namely: > > * White Lists > * Consent > * Circles of Trust > > I don't believe there is much to be standardized with the last green > solution, > Centralized Providers. > > -d > > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Hannes Tschofenig >> Sent: Tuesday, April 01, 2008 12:57 PM >> To: rucus BoF >> Subject: [Rucus] Next Steps towards the EG >> >> A little time passed after the IETF meeting and now we need >> to go back >> to work. >> >> We now need to determine the expected outcome of the >> Exploratory Group >> (otherwise it cannot get chartered). >> >> My impression from the discussion at the IETF meeting was >> that we would >> want to determine what mechanisms (that got proposed so far) >> are useful >> enough for most of the folks in the group to later work on. >> To make it a >> bit more "challenging" we should limit the number of items we want to >> standardize to a small number. Let's say "3". >> >> Is that a useful expected outcome? Decide on 3 solution >> approaches that >> we would like to standardize. >> We would obviously want to describe on what "properties" we >> get when we >> have these three mechanisms. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Apr 1 21:24:06 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F09AF3A6E8C; Tue, 1 Apr 2008 21:24:06 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EC953A6E50 for ; Tue, 1 Apr 2008 21:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU3lPVmPKd42 for ; Tue, 1 Apr 2008 21:24:05 -0700 (PDT) Received: from dizzyd.com (dizzyd.com [207.210.219.225]) by core3.amsl.com (Postfix) with ESMTP id DD5443A6B1C for ; Tue, 1 Apr 2008 21:24:04 -0700 (PDT) Received: from dialup-4.227.197.38.Dial1.Denver1.Level3.net (dialup-4.227.197.38.Dial1.Denver1.Level3.net [4.227.197.38]) (Authenticated sender: stpeter) by dizzyd.com (Postfix) with ESMTPSA id 807DC40053; Tue, 1 Apr 2008 22:23:10 -0600 (MDT) Message-ID: <47F30A5B.8030508@stpeter.im> Date: Tue, 01 Apr 2008 22:23:55 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.12) Gecko/20080213 Thunderbird/2.0.0.12 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Dan Wing References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> In-Reply-To: <1a4601c8944c$de7a9520$c5f0200a@cisco.com> Cc: 'rucus BoF' Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1794428114==" Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1794428114== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000609040007070709060701" This is a cryptographically signed message in MIME format. --------------ms000609040007070709060701 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dan Wing wrote: > I propose that RUCUS concentrate on the first three listed as green, namely: > > * White Lists > * Consent > * Circles of Trust +1 Peter -- Peter Saint-Andre https://stpeter.im/ --------------ms000609040007070709060701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIYQDCC B3AwggbZoAMCAQICAQowDQYJKoZIhvcNAQEEBQAwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQI EwZJc3JhZWwxDjAMBgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYD VQQLExFDQSBBdXRob3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlv biBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzAeFw0wNTA0 MDUxNDUyMTNaFw0xMDA0MDQxNDUyMTNaMIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMGSXNy YWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlmaWNh dGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWlsIEZy ZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZzCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPEaOcSx5ZNexwo1zJNcX48UV0UtkNtWX3qa9ZaX2VZilgIz eIrObloQV0Ma2rdgqosW9xMb5u3lBVIumt7fEwgMqqtDa3F2Qudelv93P9z2nbmn7X4GnCKA IQcW97KOSgQQHaVPHq03xGFbszx+LOKrBi/xv3bcGxtYrH+10M1nHbCRo8U2+zcJQowxoI+O U5nhko9vU25Jp8ZQ2fROH6C2TSjZuanzMTyvc5+dJiN2Hm2MhAMrqO7pUGhDKuUvnmKpAcwj eYQHU51mvlB4IId+4bTEwVoG4AMJ8RXB47VdJevN0yqeJSACyoRft4w4OpqFysR1HTT6aE6u xLg9ZC0CAwEAAaOCBBMwggQPMA8GA1UdEwEB/wQFMAMBAf8wCwYDVR0PBAQDAgHmMB0GA1Ud DgQWBBQErNskd1NGRpZfFwFcfUJHvUgZCDCB3QYDVR0jBIHVMIHSgBQcicOWzL3+MtUNjIEx tpidjShkjaGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UE BxMFRWlsYXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0 eSBEZXAuMSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEAMB0GA1UdEQQWMBSBEmFkbWluQHN0 YXJ0Y29tLm9yZzAdBgNVHRIEFjAUgRJhZG1pbkBzdGFydGNvbS5vcmcwYgYDVR0fBFswWTAp oCegJYYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2NhLWNybC5jcmwwLKAqoCiGJmh0dHA6 Ly9jcmwuc3RhcnRjb20ub3JnL2NybC9jYS1jcmwuY3JsMIIBSgYDVR0gBIIBQTCCAT0wggE5 BgsrBgEEAYG1NwEBATCCASgwLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9y Zy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvaW50 ZXJtZWRpYXRlLnBkZjCBvQYIKwYBBQUHAgIwgbAwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGX TGltaXRlZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25z KiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWls YWJsZSBhdCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhC AQEEBAMCAAcwUAYJYIZIAYb4QgENBEMWQVN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRl cm1lZGlhdGUgRnJlZSBTU0wgRW1haWwgQ2VydGlmaWNhdGVzMDIGCWCGSAGG+EIBBAQlFiNo dHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY2EtY3JsLmNybDAzBglghkgBhvhCAQMEJhYkaHR0 cDovL2NlcnQuc3RhcnRjb20ub3JnL2NydC1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRw Oi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjANBgkqhkiG9w0BAQQFAAOBgQBc1g6H yT3ZrGb0Kq+kkqetnSXtcwffHEr6Tia2XqCqPLLzdZ8VTxVjeq/Kpg2u+8cGASIl1U45XmWa v4Vez+jSSnChRHwidmbwjCtNBFxr4C/Nkgs8wk2zNQbh+zlDKNophJT7+DVOhnIMJzdNkQW0 4STurMCFwLoyx5k1rDHQYTCCCGIwggdKoAMCAQICAwF4qjANBgkqhkiG9w0BAQUFADCBrzEL MAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEj MCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAtBgNVBAMTJlN0YXJ0Q29t IENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZIhvcNAQkBFhJhZG1pbkBz dGFydGNvbS5vcmcwHhcNMDcwODIyMjExMzI3WhcNMDgwODIxMjExMzI3WjCBujELMAkGA1UE BhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxGjAYBgNVBAoTEVBl dGVyIFNhaW50LUFuZHJlMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALC1dkqD gghuvUCkEloRDX50TTJ6Szj1BqtMpYq+An66BwkWfP07uay+jHori77776wk1/Ajk1nTSHX+ JWo+JWwVXYWBX+Zd780bB0FGShYlHGwMhd/pxX9sT4KW3D+r8sIHVbTGdudSweuNdBhqr1iE cjze75hpywMkk1OQhTkseQxI5owa9M31JOdNEX0Ja6esyhwwtqqTNC86OujXwa2wew8GTRJE 9p2I0B1VCsKuJaPatbIcf9OFiTSODb5vyoq3+lrElh6V6BXKxEfQ4D2HCSY+5UmlKdnltzvN bqxyaTYQi1YGsFzew7ST3R8P5jrCq2cvRjGrTKVojZXgPZ0CAwEAAaOCBHgwggR0MAwGA1Ud EwQFMAMCAQAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAd BgNVHQ4EFgQUl7CU2dS/alOwLIHV/Oc2RkGDYugwgd0GA1UdIwSB1TCB0oAUBKzbJHdTRkaW XxcBXH1CR71IGQihgbakgbMwgbAxCzAJBgNVBAYTAklMMQ8wDQYDVQQIEwZJc3JhZWwxDjAM BgNVBAcTBUVpbGF0MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMRowGAYDVQQLExFDQSBBdXRo b3JpdHkgRGVwLjEpMCcGA1UEAxMgRnJlZSBTU0wgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkx ITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZ4IBCjCCAUAGA1UdIASCATcwggEz MIIBLwYLKwYBBAGBtTcBAQQwggEeMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvaW50ZXJtZWRpYXRlLnBkZjAvBggrBgEFBQcCARYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwgbMGCCsGAQUFBwICMIGmMBQWDVN0YXJ0Q29tIEx0ZC4wAwIB ARqBjUxpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gUG9saWN5IGF2YWlsYWJsZSBh dCBodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9saWN5LnBkZjBkBgNVHR8EXTBbMCygKqAo hiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDov L2NybC5zdGFydGNvbS5vcmcvY3J0dTMtY3JsLmNybDCBhAYIKwYBBQUHAQEEeDB2MDcGCCsG AQUFBzABhitodHRwOi8vb2NzcC5zdGFydGNvbS5vcmcvc3ViL2NsYXNzMy91c2VyL2NhMDsG CCsGAQUFBzAChi9odHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc3ViLmNsYXNzMy51c2VyLmNh LmNydDARBglghkgBhvhCAQEEBAMCBaAwMQYJYIZIAYb4QgENBCQWIlN0YXJ0Q29tIFRydXN0 ZWQgRW1haWwgQ2VydGlmaWNhdGUwMgYJYIZIAYb4QgEEBCUWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9jYS1jcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvY3J0dTMtY3JsLmNybDAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NlcnQuc3RhcnRj b20ub3JnL3BvbGljeS5wZGYwIwYDVR0SBBwwGoYYaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn MA0GCSqGSIb3DQEBBQUAA4IBAQCdG1L0T4OT1x4X/cKsuHxgijRaZGGiVECcn5+1X7E3H54/ yDkUqWAp6MZ3hZm36pzTYYnl+5M6vldLcqFCVpD7MgH6Kmu+r6pXAjU33k1RIHnkBvQ6KGlR p0RjfaZW/2MkG07vF2QTLbx6KIhi0pa9Bg9wlqyw+C2g6FYnfmrdJLgGrxUXek8DSZNjZ/AA 75OoutrWkBtdaL2TbFiawdbGuJbSoQLHqLrNhT8f74Oec7ReOmuUTEL8hsFU0sbY/n2e9Wna 1Vzze3nZPbyPiC5F88p88gVLB9mKkOzleYefYiQw8LABz5x1MI+w0bNKNPLviJ/KnHGFEfVL z1oMHyC3MIIIYjCCB0qgAwIBAgIDAXiqMA0GCSqGSIb3DQEBBQUAMIGvMQswCQYDVQQGEwJJ TDEPMA0GA1UECBMGSXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpT ZWN1cmUgQ2VydGlmaWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQ cmltYXJ5IEVtYWlsIEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9y ZzAeFw0wNzA4MjIyMTEzMjdaFw0wODA4MjEyMTEzMjdaMIG6MQswCQYDVQQGEwJVUzERMA8G A1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEaMBgGA1UEChMRUGV0ZXIgU2FpbnQt QW5kcmUxLDAqBgNVBAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRow GAYDVQQDExFQZXRlciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBl dGVyLmltMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsLV2SoOCCG69QKQSWhEN fnRNMnpLOPUGq0ylir4CfroHCRZ8/Tu5rL6MeiuLvvvvrCTX8COTWdNIdf4laj4lbBVdhYFf 5l3vzRsHQUZKFiUcbAyF3+nFf2xPgpbcP6vywgdVtMZ251LB6410GGqvWIRyPN7vmGnLAyST U5CFOSx5DEjmjBr0zfUk500RfQlrp6zKHDC2qpM0Lzo66NfBrbB7DwZNEkT2nYjQHVUKwq4l o9q1shx/04WJNI4Nvm/Kirf6WsSWHpXoFcrER9DgPYcJJj7lSaUp2eW3O81urHJpNhCLVgaw XN7DtJPdHw/mOsKrZy9GMatMpWiNleA9nQIDAQABo4IEeDCCBHQwDAYDVR0TBAUwAwIBADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSX sJTZ1L9qU7AsgdX85zZGQYNi6DCB3QYDVR0jBIHVMIHSgBQErNskd1NGRpZfFwFcfUJHvUgZ CKGBtqSBszCBsDELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEOMAwGA1UEBxMFRWls YXQxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xGjAYBgNVBAsTEUNBIEF1dGhvcml0eSBEZXAu MSkwJwYDVQQDEyBGcmVlIFNTTCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEhMB8GCSqGSIb3 DQEJARYSYWRtaW5Ac3RhcnRjb20ub3JnggEKMIIBQAYDVR0gBIIBNzCCATMwggEvBgsrBgEE AYG1NwEBBDCCAR4wNQYIKwYBBQUHAgEWKWh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRl cm1lZGlhdGUucGRmMC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjCBswYIKwYBBQUHAgIwgaYwFBYNU3RhcnRDb20gTHRkLjADAgEBGoGNTGltaXRl ZCBMaWFiaWxpdHksIHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0 aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMGQGA1UdHwRdMFswLKAqoCiGJmh0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0 Y29tLm9yZy9jcnR1My1jcmwuY3JsMIGEBggrBgEFBQcBAQR4MHYwNwYIKwYBBQUHMAGGK2h0 dHA6Ly9vY3NwLnN0YXJ0Y29tLm9yZy9zdWIvY2xhc3MzL3VzZXIvY2EwOwYIKwYBBQUHMAKG L2h0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9zdWIuY2xhc3MzLnVzZXIuY2EuY3J0MBEGCWCG SAGG+EIBAQQEAwIFoDAxBglghkgBhvhCAQ0EJBYiU3RhcnRDb20gVHJ1c3RlZCBFbWFpbCBD ZXJ0aWZpY2F0ZTAyBglghkgBhvhCAQQEJRYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2Nh LWNybC5jcmwwNQYJYIZIAYb4QgEDBCgWJmh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9jcnR1 My1jcmwuY3JsMDIGCWCGSAGG+EIBCAQlFiNodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvcG9s aWN5LnBkZjAjBgNVHRIEHDAahhhodHRwOi8vY2VydC5zdGFydGNvbS5vcmcwDQYJKoZIhvcN AQEFBQADggEBAJ0bUvRPg5PXHhf9wqy4fGCKNFpkYaJUQJyfn7VfsTcfnj/IORSpYCnoxneF mbfqnNNhieX7kzq+V0tyoUJWkPsyAfoqa76vqlcCNTfeTVEgeeQG9DooaVGnRGN9plb/YyQb Tu8XZBMtvHooiGLSlr0GD3CWrLD4LaDoVid+at0kuAavFRd6TwNJk2Nn8ADvk6i62taQG11o vZNsWJrB1sa4ltKhAseous2FPx/vg55ztF46a5RMQvyGwVTSxtj+fZ71adrVXPN7edk9vI+I LkXzynzyBUsH2YqQ7OV5h59iJDDwsAHPnHUwj7DRs0o08u+In8qccYUR9UvPWgwfILcxggQs MIIEKAIBATCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQGA1UEChMN U3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25pbmcxLzAt BgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEwHwYJKoZI hvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjAJBgUrDgMCGgUAoIICSTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODA0MDIwNDIzNTVaMCMGCSqG SIb3DQEJBDEWBBTL8ZFLpUmmBatBbP6qszRd/OPEUTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG 9w0DAgIBKDCByAYJKwYBBAGCNxAEMYG6MIG3MIGvMQswCQYDVQQGEwJJTDEPMA0GA1UECBMG SXNyYWVsMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSMwIQYDVQQLExpTZWN1cmUgQ2VydGlm aWNhdGUgU2lnbmluZzEvMC0GA1UEAxMmU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEVtYWls IEZyZWUgQ0ExITAfBgkqhkiG9w0BCQEWEmFkbWluQHN0YXJ0Y29tLm9yZwIDAXiqMIHKBgsq hkiG9w0BCRACCzGBuqCBtzCBrzELMAkGA1UEBhMCSUwxDzANBgNVBAgTBklzcmFlbDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjEjMCEGA1UECxMaU2VjdXJlIENlcnRpZmljYXRlIFNpZ25p bmcxLzAtBgNVBAMTJlN0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBFbWFpbCBGcmVlIENBMSEw HwYJKoZIhvcNAQkBFhJhZG1pbkBzdGFydGNvbS5vcmcCAwF4qjANBgkqhkiG9w0BAQEFAASC AQBcde7dvbnzJdGvgoVXkCU19GUY75fjLREF6MTdVUmRCeK6uIMSVgLKyx64MK4kY6Al3q/o lDKo7y/jL6dl8nzf4W/pGdmH0kBnGb9gyWWWEmUGCkwsEyLt8Imu1Mub66NZArdhQDp+Tm2z C6QUBAnDddnoyeekugTliN5kl7aYY9DZA4WtpQxEERuYW+hyanRyOdYU83R7rROkkkEHl98A 8I0rLYagxq9eEfEP6diqCFjAUoxxUCl2p7OgDyBT45+QUOBvlh79WQe1p8qh4qSbvadNorNn Uo9kU9aZHo3hfhZvmUo3liXfTy0CCKH2UDa8SXD45fWKOEgeUbCtS48BAAAAAAAA --------------ms000609040007070709060701-- --===============1794428114== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus --===============1794428114==-- From rucus-bounces@ietf.org Tue Apr 1 21:38:13 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8325C3A6CF0; Tue, 1 Apr 2008 21:38:13 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 732443A6CF0 for ; Tue, 1 Apr 2008 21:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.862 X-Spam-Level: X-Spam-Status: No, score=-5.862 tagged_above=-999 required=5 tests=[AWL=2.737, BAYES_00=-2.599, MANGLED_SPAM=2.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9agL6r1UH0v for ; Tue, 1 Apr 2008 21:38:10 -0700 (PDT) Received: from gal.iecc.com (gal.iecc.com [208.31.42.53]) by core3.amsl.com (Postfix) with ESMTP id 6B9413A6DB1 for ; Tue, 1 Apr 2008 21:38:10 -0700 (PDT) Received: (qmail 93289 invoked from network); 2 Apr 2008 04:38:09 -0000 Received: from simone.iecc.com (208.31.42.47) by mail1.iecc.com with QMQP; 2 Apr 2008 04:38:09 -0000 Date: 2 Apr 2008 04:38:09 -0000 Message-ID: <20080402043809.63168.qmail@simone.iecc.com> From: John Levine To: rucus@ietf.org In-Reply-To: <47F29396.9070503@gmx.net> Organization: X-Headerized: yes Mime-Version: 1.0 Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org >My impression from the discussion at the IETF meeting was that we >would want to determine what mechanisms (that got proposed so far) >are useful enough for most of the folks in the group to later work >on. To make it a bit more "challenging" we should limit the number of >items we want to standardize to a small number. Let's say "3". I'm trying to figure out a constructive way to say this, but based on the discussion I've seen so far, I would be concerned that many of the participants are relatively new to abuse issues, and that it's hard to predict whether an anti-abuse technique will be effective even when you've been doing this stuff for a while. After a decade in the email anti-spam trenches, I cannot tell you how many times people have arrived with great enthusiasm for techniques that don't work at all. (That's why I'm working on the wiki of anti-spam techniques at http://wiki.asrg.sp.am, largely to document our failures so we don't have to repeat them.) Or something works for a while, the spammers learn to evade it, and then we get into big fights about whether to change the rules about what's acceptable mail practice to plug the hole the spammers found, or to try something else. I would suggest that it's more likely to be productive to look at techniques to recognize and whitelist known good actors than to try to exclude or hide from bad actors. The set of good actors changes slowly, and their behavior probably won't change at all, so it's much more likely that whatever you come up with will continue to work. I'd agree with Dan's green list except that I happen to think that centralized (or more likely shared) whitelists are a particularly promising approach. R's, John Levine, grizzled old ASRG chair _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Apr 1 23:48:12 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96D573A6C69; Tue, 1 Apr 2008 23:48:12 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA38F3A6881 for ; Tue, 1 Apr 2008 23:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl2ouiru6KxL for ; Tue, 1 Apr 2008 23:48:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 0694928C22E for ; Tue, 1 Apr 2008 23:48:08 -0700 (PDT) Received: (qmail 11117 invoked by uid 0); 2 Apr 2008 06:48:08 -0000 Received: from 192.100.124.219 by www177.gmx.net with HTTP; Wed, 02 Apr 2008 08:48:07 +0200 (CEST) Date: Wed, 02 Apr 2008 08:48:07 +0200 From: "Hannes Tschofenig" In-Reply-To: <47F9FF99-40EA-4B13-8C3F-8994B3DBEF0F@cs.columbia.edu> Message-ID: <20080402064807.40330@gmx.net> MIME-Version: 1.0 References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F9FF99-40EA-4B13-8C3F-8994B3DBEF0F@cs.columbia.edu> To: Henning Schulzrinne , dwing@cisco.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19qWXdycgNqKXtmzCPKu1Qp+3etKD7UK6WPzfA81/ 1Gr5hOucUm8JFCtIGhvzUujxhLbu0wc6/9uQ== X-GMX-UID: FRXLcv18bmwoJYERqjZLA41PUzc4clF2 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Hennig, I was looking for this type of feedback since I was actually proposing this "framework" approach as you indicated. Then, Jonathan came along with his idea to write drafts for each individual approach and indicate what the properties are and then to select something. To my surprise people liked his approach, at least at the BOF. While I understand that we have to pick a specific mechanism later on I believe that most mechanisms treated in isolation are pretty useless. The only make sense in the context of some architectural assumptions. Consider, for example, user-written white lists: They obviously make only sense if there is a way to solve the introduction problem and when you have some strong identity mechanisms. Then, when the evalutation of the identity is done at the end host and the policies are only available at the end host then there is no protocol work todo since the white list handling is purely an implementation issue. Ciao Hannes -------- Original-Nachricht -------- > Datum: Tue, 1 Apr 2008 19:44:25 -0400 > Von: Henning Schulzrinne > An: Dan Wing > CC: "\'Hannes Tschofenig\'" , "\'rucus BoF\'" > Betreff: Re: [Rucus] Next Steps towards the EG > Hannes should speak for himself, but I thought we were talking a bit > more general, rather than specific spam prevention solutions. For > example, one tool that's been discussed repeatedly is the marking of > calls and the various call treatment options. I don't think it's > particularly productive to go through all the spam techniques. > > On Apr 1, 2008, at 7:05 PM, Dan Wing wrote: > > Jonathan's presentation at the Philadelphia RUCUS meeting, "RFC 5039 > > Overview" > > , had a > > slide that > > showed each RFC5039 solution in red, yellow, and green. The intent, > > as I > > understood it, is that red meant solutions that were difficult to > > implement or > > were not likely to be successful, green is for solutions that should > > be > > relatively easy to implement and should be relatively successful, > > and yellow > > is between green and red. > > > > Red solutions: > > * Content Filtering > > * Address Obfuscation > > * Computational Puzzles > > * Payments at Risk > > > > Yellow solutions: > > * Black Lists > > * Reputation > > * Limited Use Addresses > > * Turing Tests > > * Legal Action > > > > Green solutions: > > * White Lists > > * Consent > > * Circles of Trust > > * Centralized Providers > > > > and text to the right on Jonathan's slide said "Strong Identity a > > Key For Many > > of these!". > > > > > > > > I propose that RUCUS concentrate on the first three listed as green, > > namely: > > > > * White Lists > > * Consent > > * Circles of Trust > > > > I don't believe there is much to be standardized with the last green > > solution, > > Centralized Providers. > > > > -d > > > > > >> -----Original Message----- > >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > >> On Behalf Of Hannes Tschofenig > >> Sent: Tuesday, April 01, 2008 12:57 PM > >> To: rucus BoF > >> Subject: [Rucus] Next Steps towards the EG > >> > >> A little time passed after the IETF meeting and now we need > >> to go back > >> to work. > >> > >> We now need to determine the expected outcome of the > >> Exploratory Group > >> (otherwise it cannot get chartered). > >> > >> My impression from the discussion at the IETF meeting was > >> that we would > >> want to determine what mechanisms (that got proposed so far) > >> are useful > >> enough for most of the folks in the group to later work on. > >> To make it a > >> bit more "challenging" we should limit the number of items we want to > >> standardize to a small number. Let's say "3". > >> > >> Is that a useful expected outcome? Decide on 3 solution > >> approaches that > >> we would like to standardize. > >> We would obviously want to describe on what "properties" we > >> get when we > >> have these three mechanisms. > >> > >> Ciao > >> Hannes > >> > >> > >> _______________________________________________ > >> Rucus mailing list > >> Rucus@ietf.org > >> https://www.ietf.org/mailman/listinfo/rucus > > > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Apr 2 06:06:07 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4153A6EFD; Wed, 2 Apr 2008 06:06:07 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30FF3A6AB8 for ; Wed, 2 Apr 2008 06:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSnABNZ4eGUm for ; Wed, 2 Apr 2008 06:06:01 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id 8E97728C54A for ; Wed, 2 Apr 2008 06:05:23 -0700 (PDT) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id 1CC042C022E10 for ; Wed, 2 Apr 2008 15:05:24 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhhcGBsU32e2 for ; Wed, 2 Apr 2008 15:05:24 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id F22BB2C022DEC for ; Wed, 2 Apr 2008 15:05:18 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Apr 2008 15:05:19 +0200 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF5C5161@mx1.office> In-Reply-To: <20080402064807.40330@gmx.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Next Steps towards the EG Thread-Index: AciUjZYYAaSUQEQ+QU6jFnJY6uJrwAAMxtdw References: <47F29396.9070503@gmx.net><1a4601c8944c$de7a9520$c5f0200a@cisco.com><47F9FF99-40EA-4B13-8C3F-8994B3DBEF0F@cs.columbia.edu> <20080402064807.40330@gmx.net> From: "Saverio Niccolini" To: Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I think the more general approach makes more sense and I see it more in the scope of an exploratory group. This does not exclude that the document where the general approach will be described will also have a list of some techniques (no more than 2 pages for each) that will be ranked for thei success probability (like green, yellow, red). Thus my (concrete) proposal would be: -- general reference scenario (start from spitstop draft, add the consideration Otmar/David/others posted, in the end it is enough to summarize Henning presentation at the BOF) -- proposal for a framework mapping to the scenario (start from Hannes draft) -- list of potential proposal with related ranking (start from classification of Jonathan, add the mechanisms he left out and that where proposed in various draft) --> We have the document :-) Only if we make successful investigations in this sense we will have a chance to build standard that will address the real problem I hope you like it :-) Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Hannes Tschofenig > Sent: Wednesday, April 02, 2008 8:48 AM > To: Henning Schulzrinne; dwing@cisco.com > Cc: rucus@ietf.org > Subject: Re: [Rucus] Next Steps towards the EG > > Hi Hennig, > > I was looking for this type of feedback since I was actually > proposing this "framework" approach as you indicated. Then, > Jonathan came along with his idea to write drafts for each > individual approach and indicate what the properties are and > then to select something. To my surprise people liked his > approach, at least at the BOF. > > While I understand that we have to pick a specific mechanism > later on I believe that most mechanisms treated in isolation > are pretty useless. The only make sense in the context of > some architectural assumptions. > > Consider, for example, user-written white lists: They > obviously make only sense if there is a way to solve the > introduction problem and when you have some strong identity > mechanisms. Then, when the evalutation of the identity is > done at the end host and the policies are only available at > the end host then there is no protocol work todo since the > white list handling is purely an implementation issue. > > Ciao > Hannes > > -------- Original-Nachricht -------- > > Datum: Tue, 1 Apr 2008 19:44:25 -0400 > > Von: Henning Schulzrinne > > An: Dan Wing > > CC: "\'Hannes Tschofenig\'" , "\'rucus > > BoF\'" > > Betreff: Re: [Rucus] Next Steps towards the EG > > > Hannes should speak for himself, but I thought we were > talking a bit > > more general, rather than specific spam prevention solutions. For > > example, one tool that's been discussed repeatedly is the > marking of > > calls and the various call treatment options. I don't think it's > > particularly productive to go through all the spam techniques. > > > > On Apr 1, 2008, at 7:05 PM, Dan Wing wrote: > > > Jonathan's presentation at the Philadelphia RUCUS > meeting, "RFC 5039 > > > Overview" > > > > , had a > > > slide that showed each RFC5039 solution in red, yellow, > and green. > > > The intent, as I understood it, is that red meant solutions that > > > were difficult to implement or were not likely to be successful, > > > green is for solutions that should be relatively easy to > implement > > > and should be relatively successful, and yellow is > between green and > > > red. > > > > > > Red solutions: > > > * Content Filtering > > > * Address Obfuscation > > > * Computational Puzzles > > > * Payments at Risk > > > > > > Yellow solutions: > > > * Black Lists > > > * Reputation > > > * Limited Use Addresses > > > * Turing Tests > > > * Legal Action > > > > > > Green solutions: > > > * White Lists > > > * Consent > > > * Circles of Trust > > > * Centralized Providers > > > > > > and text to the right on Jonathan's slide said "Strong Identity a > > > Key For Many of these!". > > > > > > > > > > > > I propose that RUCUS concentrate on the first three > listed as green, > > > namely: > > > > > > * White Lists > > > * Consent > > > * Circles of Trust > > > > > > I don't believe there is much to be standardized with the > last green > > > solution, Centralized Providers. > > > > > > -d > > > > > > > > >> -----Original Message----- > > >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On > > >> Behalf Of Hannes Tschofenig > > >> Sent: Tuesday, April 01, 2008 12:57 PM > > >> To: rucus BoF > > >> Subject: [Rucus] Next Steps towards the EG > > >> > > >> A little time passed after the IETF meeting and now we > need to go > > >> back to work. > > >> > > >> We now need to determine the expected outcome of the Exploratory > > >> Group (otherwise it cannot get chartered). > > >> > > >> My impression from the discussion at the IETF meeting > was that we > > >> would want to determine what mechanisms (that got > proposed so far) > > >> are useful enough for most of the folks in the group to > later work > > >> on. > > >> To make it a > > >> bit more "challenging" we should limit the number of > items we want > > >> to standardize to a small number. Let's say "3". > > >> > > >> Is that a useful expected outcome? Decide on 3 solution > approaches > > >> that we would like to standardize. > > >> We would obviously want to describe on what "properties" we get > > >> when we have these three mechanisms. > > >> > > >> Ciao > > >> Hannes > > >> > > >> > > >> _______________________________________________ > > >> Rucus mailing list > > >> Rucus@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rucus > > > > > > _______________________________________________ > > > Rucus mailing list > > > Rucus@ietf.org > > > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Apr 2 07:52:52 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0293B28C58E; Wed, 2 Apr 2008 07:52:52 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AA1628C564 for ; Wed, 2 Apr 2008 07:52:50 -0700 (PDT) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HV3VR2VPSsno for ; Wed, 2 Apr 2008 07:52:46 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id B6B6D3A68F7 for ; Wed, 2 Apr 2008 07:52:46 -0700 (PDT) Received: from dhcp31.cs.columbia.edu (dhcp31.cs.columbia.edu [128.59.19.231]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m32EqOio022980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 2 Apr 2008 10:52:24 -0400 (EDT) From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <20080402064807.40330@gmx.net> X-Priority: 3 References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F9FF99-40EA-4B13-8C3F-8994B3DBEF0F@cs.columbia.edu> <20080402064807.40330@gmx.net> Message-Id: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 2 Apr 2008 10:52:23 -0400 X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On Apr 2, 2008, at 2:48 AM, Hannes Tschofenig wrote: > Hi Hennig, > > I was looking for this type of feedback since I was actually > proposing this "framework" approach as you indicated. Then, Jonathan > came along with his idea to write drafts for each individual > approach and indicate what the properties are and then to select > something. To my surprise people liked his approach, at least at the > BOF. Having informal description of the properties seems like a useful project, but John's/ASRG Wiki may well serve this purpose. Even for more architectural and protocol work, we clearly have to pick a set of general techniques we envision as being most useful and plausible. There's no need to think about building a global micro-payment protocol, say, if we don't believe that micro-payments are likely to be useful or (economically/legally) feasible. So far, identity and statistical-property-based approaches seem most promising, corresponding to the 'green' list. Henning _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Wed Apr 2 15:52:47 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A343D28C272; Wed, 2 Apr 2008 15:52:47 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B43B428C272 for ; Wed, 2 Apr 2008 15:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VFnlexgoWza for ; Wed, 2 Apr 2008 15:52:39 -0700 (PDT) Received: from balder-227.proper.com (unknown [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 33EA728C20D for ; Wed, 2 Apr 2008 15:52:39 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m32MqU2t018300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 2 Apr 2008 15:52:31 -0700 (MST) (envelope-from paul.hoffman@domain-assurance.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1a4601c8944c$de7a9520$c5f0200a@cisco.com> References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> Date: Wed, 2 Apr 2008 15:52:28 -0700 To: From: Paul Hoffman Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org At 4:05 PM -0700 4/1/08, Dan Wing wrote: >I propose that RUCUS concentrate on the first three listed as green, namely: > > * White Lists > * Consent > * Circles of Trust > Indeed. There are reasonable areas of exploration in each of these, and they do avoid many of the ratholes on the red list. Note that "reputation" and "white lists" go hand-in-hand, but it's probably a different "reputation" than RAI folks are used to. Someone putting together a white list does so based on some knowledge of the organizations listed. That is, in essence, reputation. I think the "yellow list" reputation is "every end node needs to be keeping track of the reputation of every other party, and that is indeed yellow/red list fodder. --Paul Hoffman, Director --Domain Assurance Council _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Apr 3 01:43:13 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4AB228C108; Thu, 3 Apr 2008 01:43:13 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51FA28C108 for ; Thu, 3 Apr 2008 01:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWLKe2Hh-emU for ; Thu, 3 Apr 2008 01:43:12 -0700 (PDT) Received: from mail.bofh.priv.at (fardach.bofh.priv.at [88.198.34.164]) by core3.amsl.com (Postfix) with ESMTP id 2BEBC3A6F5D for ; Thu, 3 Apr 2008 01:43:07 -0700 (PDT) Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 8EEFF4C72E; Thu, 3 Apr 2008 10:43:09 +0200 (CEST) Date: Thu, 3 Apr 2008 10:43:09 +0200 From: Otmar Lendl To: John Levine Message-ID: <20080403084309.GA420@bofh.priv.at> Mail-Followup-To: Otmar Lendl , John Levine , rucus@ietf.org References: <47F29396.9070503@gmx.net> <20080402043809.63168.qmail@simone.iecc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20080402043809.63168.qmail@simone.iecc.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org On 2008/04/02 06:04, John Levine wrote: > > I'm trying to figure out a constructive way to say this, but based on > the discussion I've seen so far, I would be concerned that many of the > participants are relatively new to abuse issues, and that it's hard to > predict whether an anti-abuse technique will be effective even when > you've been doing this stuff for a while. :-) I've spent too much time of my life running mail servers not to agree with you. > I would suggest that it's more likely to be productive to look at > techniques to recognize and whitelist known good actors than to try to > exclude or hide from bad actors. The set of good actors changes > slowly, and their behavior probably won't change at all, so it's much > more likely that whatever you come up with will continue to work. I fully agree with you here. My take is in Section 4.1 of draft-lendl-speermint-background-01. As long as you assume the full email-model where every single IP address on the Internet is a potentially valid source of a call / email leads to an IMHO unsolvable SPAM/SPIT problem. As I see it, as long as you don't revisit that assumption, you are going to fail. Detecting good actors is the only way to go. As you write, this is a lot easier that just trying to detect the bad guys. As I see the problem space, there is only one missing piece in the architecture: How do you route a call if the sending network is not recognized by receiving network as a "white hat"? /ol -- -=- Otmar Lendl -- ol@bofh.priv.at -=- _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Apr 3 02:04:56 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9BCB3A6B8C; Thu, 3 Apr 2008 02:04:55 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 35B1B3A6979 for ; Thu, 3 Apr 2008 02:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIbUPu4jInAP for ; Thu, 3 Apr 2008 02:04:48 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 025C928C4E3 for ; Thu, 3 Apr 2008 02:04:47 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m3393IVp022515; Thu, 3 Apr 2008 11:03:20 +0200 Received: from [139.54.131.75] ([139.54.131.75]) by FRVELSBHS02.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Thu, 3 Apr 2008 11:04:46 +0200 Message-ID: <47F49DAA.9030902@alcatel-lucent.fr> Date: Thu, 03 Apr 2008 11:04:42 +0200 From: Thomas Froment User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <47F29396.9070503@gmx.net> In-Reply-To: <47F29396.9070503@gmx.net> X-OriginalArrivalTime: 03 Apr 2008 09:04:46.0923 (UTC) FILETIME=[C3CE21B0:01C89569] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Cc: rucus BoF Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org My understanding was that a there was a reasonnable consensus to fo forward with Jonathan's proposal. So, goal of the RUCUS charter would not be to focus *right now* on (only) 3 mechanisms, but to define *what kind of contribution* could be expected from RUCUS EG. What about this proposal? Hannes Tschofenig wrote: > A little time passed after the IETF meeting and now we need to go back > to work. > > We now need to determine the expected outcome of the Exploratory Group > (otherwise it cannot get chartered). > > My impression from the discussion at the IETF meeting was that we would > want to determine what mechanisms (that got proposed so far) are useful > enough for most of the folks in the group to later work on. To make it a > bit more "challenging" we should limit the number of items we want to > standardize to a small number. Let's say "3". > > Is that a useful expected outcome? Decide on 3 solution approaches that > we would like to standardize. > We would obviously want to describe on what "properties" we get when we > have these three mechanisms. > > Ciao > Hannes > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Apr 3 08:24:46 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3B328C6F0; Thu, 3 Apr 2008 08:24:46 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9768C3A6C16 for ; Thu, 3 Apr 2008 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX6x5A3I3Zi5 for ; Thu, 3 Apr 2008 08:24:40 -0700 (PDT) Received: from smtp0.neclab.eu (smtp0.neclab.eu [195.37.70.41]) by core3.amsl.com (Postfix) with ESMTP id D2AC53A6929 for ; Thu, 3 Apr 2008 08:24:39 -0700 (PDT) Received: from localhost (localhost.office [127.0.0.1]) by smtp0.neclab.eu (Postfix) with ESMTP id EF9552C03BE24; Thu, 3 Apr 2008 17:24:42 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas2.office) Received: from smtp0.neclab.eu ([127.0.0.1]) by localhost (atlas2.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p96iH69jjqOu; Thu, 3 Apr 2008 17:24:42 +0200 (CEST) Received: from mx1.office (mx1.office [10.1.1.23]) by smtp0.neclab.eu (Postfix) with ESMTP id D8DEE2C03BE25; Thu, 3 Apr 2008 17:24:27 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 3 Apr 2008 17:24:27 +0200 Message-ID: <5F6519BF2DE0404D99B7C75607FF76FF630A8E@mx1.office> In-Reply-To: <47F49DAA.9030902@alcatel-lucent.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Rucus] Next Steps towards the EG Thread-Index: AciVadsUHJtESkabTrSVkpe1ae8rRAANG4TA References: <47F29396.9070503@gmx.net> <47F49DAA.9030902@alcatel-lucent.fr> From: "Saverio Niccolini" To: "Thomas Froment" , "Hannes Tschofenig" Cc: rucus BoF Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org I support the direction "what kind of contirbution do we need" much more than "let's identify 3 mechanisms and standardize them" As I said already (nobody commented so far), in my opinon the RUCUS output should be: -- reference scenario -- reference framework -- list of potential solutions (categories, not mechanism x/y) with properties and expected impact in solving the problem Saverio ============================================================ Dr. Saverio Niccolini Senior Researcher NEC Laboratories Europe, Network Research Division Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-118 Fax: +49 (0)6221 4342-155 e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! ============================================================ NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014 > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Thomas Froment > Sent: Thursday, April 03, 2008 11:05 AM > To: Hannes Tschofenig > Cc: rucus BoF > Subject: Re: [Rucus] Next Steps towards the EG > > My understanding was that a there was a reasonnable consensus > to fo forward with Jonathan's proposal. > So, goal of the RUCUS charter would not be to focus *right now* on > (only) 3 mechanisms, but > to define *what kind of contribution* could be expected from RUCUS EG. > > What about this proposal? > > Hannes Tschofenig wrote: > > A little time passed after the IETF meeting and now we need > to go back > > to work. > > > > We now need to determine the expected outcome of the > Exploratory Group > > (otherwise it cannot get chartered). > > > > My impression from the discussion at the IETF meeting was that we > > would want to determine what mechanisms (that got proposed > so far) are > > useful enough for most of the folks in the group to later > work on. To > > make it a bit more "challenging" we should limit the number > of items > > we want to standardize to a small number. Let's say "3". > > > > Is that a useful expected outcome? Decide on 3 solution approaches > > that we would like to standardize. > > We would obviously want to describe on what "properties" we > get when > > we have these three mechanisms. > > > > Ciao > > Hannes > > > > > > _______________________________________________ > > Rucus mailing list > > Rucus@ietf.org > > https://www.ietf.org/mailman/listinfo/rucus > > > > > > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 05:04:38 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDBE53A6B69; Sat, 5 Apr 2008 05:04:38 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07CBD3A6C9E for ; Sat, 5 Apr 2008 05:04:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.836 X-Spam-Level: X-Spam-Status: No, score=-1.836 tagged_above=-999 required=5 tests=[AWL=0.763, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwrZrgHDSG0P for ; Sat, 5 Apr 2008 05:04:34 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 70E723A684E for ; Sat, 5 Apr 2008 05:04:33 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2008 12:04:41 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp044) with SMTP; 05 Apr 2008 14:04:41 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19fv8c7TA9f5xFo8FxV0mdq8po3zLp6Td0vbWwG6B Kq0czdN7Aqq+O7 Message-ID: <47F76AD7.50109@gmx.net> Date: Sat, 05 Apr 2008 15:04:39 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F9FF99-40EA-4B13-8C3F-8994B3DBEF0F@cs.columbia.edu> <20080402064807.40330@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > > On Apr 2, 2008, at 2:48 AM, Hannes Tschofenig wrote: > >> Hi Hennig, >> >> I was looking for this type of feedback since I was actually >> proposing this "framework" approach as you indicated. Then, Jonathan >> came along with his idea to write drafts for each individual approach >> and indicate what the properties are and then to select something. To >> my surprise people liked his approach, at least at the BOF. > > Having informal description of the properties seems like a useful > project, but John's/ASRG Wiki may well serve this purpose. I would even say that we know the properties of most techniques already based on http://tools.ietf.org/html/rfc5039. For other techniques that have a close relationship to techniques proposed in the email space we already have John's Wiki. > Even for more architectural and protocol work, we clearly have to pick > a set of general techniques we envision as being most useful and > plausible. Right. > There's no need to think about building a global micro-payment > protocol, say, if we don't believe that micro-payments are likely to > be useful or (economically/legally) feasible. Correct. > > So far, identity and statistical-property-based approaches seem most > promising, corresponding to the 'green' list. Yep. Ciao Hannes > > Henning _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 05:08:41 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E3583A6B69; Sat, 5 Apr 2008 05:08:41 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DE1F28C15D for ; Sat, 5 Apr 2008 05:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLK6H4-jpxqw for ; Sat, 5 Apr 2008 05:08:38 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id DB2993A6B7C for ; Sat, 5 Apr 2008 05:08:37 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2008 12:08:45 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp033) with SMTP; 05 Apr 2008 14:08:45 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX182q/NL0Os2Xz2ugdItk/h7Qe7F0qqBBapYVvWSW7 tbJaDAMd1iFmZH Message-ID: <47F76BCB.1040100@gmx.net> Date: Sat, 05 Apr 2008 15:08:43 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Paul Hoffman References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org There are two types of white lists we have discussed in the past: * End User White Lists * Domain White Lists End user white lists do not need a repuation associated with them since they are quite likely added based on the interaction between humans. This is something like http://www.ietf.org/rfc/rfc5025.txt. Domain based white lists, on the other hand, is needed for other work we did, namely for SIP SAML. In any case, the actual white list (if someone would want to standardize the language) could be based on something we have developed as Common Policy (which is also used by RFC 5025). Ciao Hannes Paul Hoffman wrote: > At 4:05 PM -0700 4/1/08, Dan Wing wrote: > >> I propose that RUCUS concentrate on the first three listed as green, namely: >> >> * White Lists >> * Consent >> * Circles of Trust >> >> > > Indeed. There are reasonable areas of exploration in each of these, > and they do avoid many of the ratholes on the red list. > > Note that "reputation" and "white lists" go hand-in-hand, but it's > probably a different "reputation" than RAI folks are used to. Someone > putting together a white list does so based on some knowledge of the > organizations listed. That is, in essence, reputation. I think the > "yellow list" reputation is "every end node needs to be keeping track > of the reputation of every other party, and that is indeed yellow/red > list fodder. > > --Paul Hoffman, Director > --Domain Assurance Council > _______________________________________________ > Rucus mailing list > Rucus@ietf.org > https://www.ietf.org/mailman/listinfo/rucus > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 05:13:46 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C965A3A6CEA; Sat, 5 Apr 2008 05:13:46 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF7A3A6CDC for ; Sat, 5 Apr 2008 05:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.844 X-Spam-Level: X-Spam-Status: No, score=-1.844 tagged_above=-999 required=5 tests=[AWL=0.755, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgUiwCJLozIu for ; Sat, 5 Apr 2008 05:13:44 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 422393A6C9E for ; Sat, 5 Apr 2008 05:13:44 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2008 12:13:51 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp056) with SMTP; 05 Apr 2008 14:13:51 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+CHZ08KnyC9XusR13tjYClvWKZPEyOPH5tfwlbOu hZQfvMavZrBcsJ Message-ID: <47F76CFD.1070602@gmx.net> Date: Sat, 05 Apr 2008 15:13:49 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Otmar Lendl , John Levine , rucus@ietf.org References: <47F29396.9070503@gmx.net> <20080402043809.63168.qmail@simone.iecc.com> <20080403084309.GA420@bofh.priv.at> In-Reply-To: <20080403084309.GA420@bofh.priv.at> X-Y-GMX-Trusted: 0 Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org John, Otmar, many of us (if not most) agree that whitelists are very good approaches to go forward (and blacklists aren't). We had a long discussion about this issue in our work on Common Policy/Presence Authorization Policy. Otmar takes the approach one step further in the context of real-time communication in the sense that he suggests a way to deal with the introduction problem by using the ability to route calls differently. I think that's an interesting approach (and hence I have encouraged him to re-publish his draft-lendl-speermint-background-01 document). Ciao Hannes Otmar Lendl wrote: > On 2008/04/02 06:04, John Levine wrote: > >> I'm trying to figure out a constructive way to say this, but based on >> the discussion I've seen so far, I would be concerned that many of the >> participants are relatively new to abuse issues, and that it's hard to >> predict whether an anti-abuse technique will be effective even when >> you've been doing this stuff for a while. >> > > :-) > > I've spent too much time of my life running mail servers not to > agree with you. > > >> I would suggest that it's more likely to be productive to look at >> techniques to recognize and whitelist known good actors than to try to >> exclude or hide from bad actors. The set of good actors changes >> slowly, and their behavior probably won't change at all, so it's much >> more likely that whatever you come up with will continue to work. >> > > I fully agree with you here. My take is in Section 4.1 of > draft-lendl-speermint-background-01. > > As long as you assume the full email-model where every single IP address > on the Internet is a potentially valid source of a call / email leads > to an IMHO unsolvable SPAM/SPIT problem. As I see it, as long as you > don't revisit that assumption, you are going to fail. > > Detecting good actors is the only way to go. As you write, this > is a lot easier that just trying to detect the bad guys. > > As I see the problem space, there is only one missing piece in the > architecture: How do you route a call if the sending network is not > recognized by receiving network as a "white hat"? > > /ol > _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 05:15:58 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5BEC3A6CFA; Sat, 5 Apr 2008 05:15:58 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC593A6CEA for ; Sat, 5 Apr 2008 05:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umeG+GRX1djK for ; Sat, 5 Apr 2008 05:15:57 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id AB6CD3A6C5E for ; Sat, 5 Apr 2008 05:15:56 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2008 12:16:04 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp012) with SMTP; 05 Apr 2008 14:16:04 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/VBgd9M4bVtirRctTwYChYxOsLz1I/l5E42pKgnF Ejc2SiYh76ESfD Message-ID: <47F76D82.1090109@gmx.net> Date: Sat, 05 Apr 2008 15:16:02 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Thomas Froment References: <47F29396.9070503@gmx.net> <47F49DAA.9030902@alcatel-lucent.fr> In-Reply-To: <47F49DAA.9030902@alcatel-lucent.fr> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Thomas, Thomas Froment wrote: > My understanding was that a there was a reasonnable consensus to fo > forward with > Jonathan's proposal. I also asked whether the group wants to create a EG to work at all on these issues. > So, goal of the RUCUS charter would not be to focus *right now* on > (only) 3 mechanisms, but > to define *what kind of contribution* could be expected from RUCUS EG. We wouldn't focus our time in the EG on standardizing the solutions details. That's true. My question hence was indeed targeted towards the expected result from the EG. So, what would you like to see as outcome of the EG? > > What about this proposal? > Ciao Hannes > Hannes Tschofenig wrote: >> A little time passed after the IETF meeting and now we need to go >> back to work. >> >> We now need to determine the expected outcome of the Exploratory >> Group (otherwise it cannot get chartered). >> >> My impression from the discussion at the IETF meeting was that we >> would want to determine what mechanisms (that got proposed so far) >> are useful enough for most of the folks in the group to later work >> on. To make it a bit more "challenging" we should limit the number of >> items we want to standardize to a small number. Let's say "3". >> >> Is that a useful expected outcome? Decide on 3 solution approaches >> that we would like to standardize. >> We would obviously want to describe on what "properties" we get when >> we have these three mechanisms. >> >> Ciao >> Hannes >> >> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 05:17:48 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B0F23A6D29; Sat, 5 Apr 2008 05:17:48 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF4B83A6D18 for ; Sat, 5 Apr 2008 05:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.852 X-Spam-Level: X-Spam-Status: No, score=-1.852 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loZsv9fG2BcY for ; Sat, 5 Apr 2008 05:17:45 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 83B3028C211 for ; Sat, 5 Apr 2008 05:17:42 -0700 (PDT) Received: (qmail invoked by alias); 05 Apr 2008 12:17:49 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp058) with SMTP; 05 Apr 2008 14:17:49 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19nymkicOxnau9V/imP7mI8RsxsTTRaBopXEPAkKr GEmk583qsyqpbw Message-ID: <47F76DEC.4000604@gmx.net> Date: Sat, 05 Apr 2008 15:17:48 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Saverio Niccolini References: <47F29396.9070503@gmx.net> <47F49DAA.9030902@alcatel-lucent.fr> <5F6519BF2DE0404D99B7C75607FF76FF630A8E@mx1.office> In-Reply-To: <5F6519BF2DE0404D99B7C75607FF76FF630A8E@mx1.office> X-Y-GMX-Trusted: 0 Cc: rucus BoF Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Saverio Niccolini wrote: > I support the direction "what kind of contirbution do we need" > much more than "let's identify 3 mechanisms and standardize them" > > Nobody said that we would work on 3 mechanisms in the EG. > As I said already (nobody commented so far), in my opinon the > RUCUS output should be: > -- reference scenario > -- reference framework > -- list of potential solutions (categories, not mechanism x/y) > with properties and expected impact in solving the problem > > I think we are replicating the results several times. A framework describes solutions that would work together. Typically, individual solutions (at least in this space) have certain properties when used in combination with other techniques. Ciao Hannes > Saverio > > ============================================================ > Dr. Saverio Niccolini > Senior Researcher > NEC Laboratories Europe, Network Research Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 4342-118 > Fax: +49 (0)6221 4342-155 > e-mail: saverio.niccolini@nw.neclab.eu <-- !!! NEW ADDRESS !!! > ============================================================ > NEC Europe Limited Registered Office: NEC House, 1 Victoria > Road, London W3 6BL Registered in England 2832014 > > > > >> -----Original Message----- >> From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] >> On Behalf Of Thomas Froment >> Sent: Thursday, April 03, 2008 11:05 AM >> To: Hannes Tschofenig >> Cc: rucus BoF >> Subject: Re: [Rucus] Next Steps towards the EG >> >> My understanding was that a there was a reasonnable consensus >> to fo forward with Jonathan's proposal. >> So, goal of the RUCUS charter would not be to focus *right now* on >> (only) 3 mechanisms, but >> to define *what kind of contribution* could be expected from RUCUS EG. >> >> What about this proposal? >> >> Hannes Tschofenig wrote: >> >>> A little time passed after the IETF meeting and now we need >>> >> to go back >> >>> to work. >>> >>> We now need to determine the expected outcome of the >>> >> Exploratory Group >> >>> (otherwise it cannot get chartered). >>> >>> My impression from the discussion at the IETF meeting was that we >>> would want to determine what mechanisms (that got proposed >>> >> so far) are >> >>> useful enough for most of the folks in the group to later >>> >> work on. To >> >>> make it a bit more "challenging" we should limit the number >>> >> of items >> >>> we want to standardize to a small number. Let's say "3". >>> >>> Is that a useful expected outcome? Decide on 3 solution approaches >>> that we would like to standardize. >>> We would obviously want to describe on what "properties" we >>> >> get when >> >>> we have these three mechanisms. >>> >>> Ciao >>> Hannes >>> >>> >>> _______________________________________________ >>> Rucus mailing list >>> Rucus@ietf.org >>> https://www.ietf.org/mailman/listinfo/rucus >>> >>> >>> >> _______________________________________________ >> Rucus mailing list >> Rucus@ietf.org >> https://www.ietf.org/mailman/listinfo/rucus >> >> _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 15:18:24 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 705693A6B0D; Sat, 5 Apr 2008 15:18:24 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C01443A6B0D for ; Sat, 5 Apr 2008 15:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[AWL=0.878, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsKGjdJ+r1eu for ; Sat, 5 Apr 2008 15:18:22 -0700 (PDT) Received: from jalapeno.cc.columbia.edu (jalapeno.cc.columbia.edu [128.59.29.5]) by core3.amsl.com (Postfix) with ESMTP id E74BF3A69A9 for ; Sat, 5 Apr 2008 15:18:21 -0700 (PDT) Received: from [192.168.0.57] (pool-71-250-66-107.nwrknj.east.verizon.net [71.250.66.107]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id m35MIMPu008748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 5 Apr 2008 18:18:23 -0400 (EDT) Message-Id: From: Henning Schulzrinne To: Hannes Tschofenig In-Reply-To: <47F76BCB.1040100@gmx.net> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Sat, 5 Apr 2008 18:18:21 -0400 References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F76BCB.1040100@gmx.net> X-Mailer: Apple Mail (2.919.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.63 on 128.59.29.5 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org There are two kinds of end-user white lists, individual and shared. Building individual white lists ("everybody in my address book") is relatively straightforward. Building shared address lists ("everybody my friends and colleagues have called") requires a bit more work. On Apr 5, 2008, at 8:08 AM, Hannes Tschofenig wrote: > There are two types of white lists we have discussed in the past: > > * End User White Lists > * Domain White Lists > > End user white lists do not need a repuation associated with them > since > they are quite likely added based on the interaction between humans. > This is something like http://www.ietf.org/rfc/rfc5025.txt. > > Domain based white lists, on the other hand, is needed for other > work we > did, namely for SIP SAML. > > In any case, the actual white list (if someone would want to > standardize > the language) could be based on something we have developed as Common > Policy (which is also used by RFC 5025). > > Ciao > Hannes _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sat Apr 5 20:46:43 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 027E13A6945; Sat, 5 Apr 2008 20:46:43 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D16383A6A94 for ; Sat, 5 Apr 2008 20:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KneEBaWofXoz for ; Sat, 5 Apr 2008 20:46:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D256D3A69AF for ; Sat, 5 Apr 2008 20:46:39 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Sat, 5 Apr 2008 23:46:22 -0400 Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Sat, 5 Apr 2008 23:46:19 -0400 From: Hadriel Kaplan To: Hannes Tschofenig , "rucus@ietf.org" Date: Sat, 5 Apr 2008 23:45:52 -0400 Thread-Topic: [Rucus] Next Steps towards the EG Thread-Index: AciXFnc8BbZiYseMSnKr4h0pHVa+awAgc5Og Message-ID: References: <47F29396.9070503@gmx.net> <20080402043809.63168.qmail@simone.iecc.com> <20080403084309.GA420@bofh.priv.at> <47F76CFD.1070602@gmx.net> In-Reply-To: <47F76CFD.1070602@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] On Behalf Of > Hannes Tschofenig > > Otmar takes the approach one step further in the context of real-time > communication in the sense that he suggests a way to deal with the > introduction problem by using the ability to route calls differently. I > think that's an interesting approach (and hence I have encouraged him to > re-publish his draft-lendl-speermint-background-01 document). +1. It is an excellent draft. -hadriel _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Sun Apr 6 04:41:12 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE9E3A6A70; Sun, 6 Apr 2008 04:41:12 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8836B3A6937 for ; Sun, 6 Apr 2008 04:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Yjoi9vLYjda for ; Sun, 6 Apr 2008 04:41:09 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 599553A6A70 for ; Sun, 6 Apr 2008 04:41:08 -0700 (PDT) Received: (qmail invoked by alias); 06 Apr 2008 11:41:18 -0000 Received: from a91-154-103-163.elisa-laajakaista.fi (EHLO [192.168.255.4]) [91.154.103.163] by mail.gmx.net (mp028) with SMTP; 06 Apr 2008 13:41:18 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Och0l1XqOellLqy0iCwOjrI/exnoMwdynmkrSdM uafG1081XLCvmM Message-ID: <47F8B6DD.7020001@gmx.net> Date: Sun, 06 Apr 2008 14:41:17 +0300 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Henning Schulzrinne References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F76BCB.1040100@gmx.net> In-Reply-To: X-Y-GMX-Trusted: 0 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > There are two kinds of end-user white lists, individual and shared. > Building individual white lists ("everybody in my address book") is > relatively straightforward. Building shared address lists ("everybody > my friends and colleagues have called") requires a bit more work. > That's true. The later aspect would go into exploiting your relationships you have in a social network. > On Apr 5, 2008, at 8:08 AM, Hannes Tschofenig wrote: >> There are two types of white lists we have discussed in the past: >> >> * End User White Lists >> * Domain White Lists >> >> End user white lists do not need a repuation associated with them since >> they are quite likely added based on the interaction between humans. >> This is something like http://www.ietf.org/rfc/rfc5025.txt. >> >> Domain based white lists, on the other hand, is needed for other work we >> did, namely for SIP SAML. >> >> In any case, the actual white list (if someone would want to standardize >> the language) could be based on something we have developed as Common >> Policy (which is also used by RFC 5025). >> >> Ciao >> Hannes _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Mon Apr 7 06:47:03 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA6C28C364; Mon, 7 Apr 2008 06:47:03 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A745728C34E for ; Mon, 7 Apr 2008 06:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BArr0kH32les for ; Mon, 7 Apr 2008 06:46:59 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id E0F4528C304 for ; Mon, 7 Apr 2008 06:46:58 -0700 (PDT) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id m37DlAL3025634; Mon, 7 Apr 2008 08:47:10 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m37DlAA01897; Mon, 7 Apr 2008 08:47:10 -0500 (CDT) Message-ID: <47FA25DD.4070406@alcatel-lucent.com> Date: Mon, 07 Apr 2008 08:47:09 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hannes Tschofenig References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F76BCB.1040100@gmx.net> <47F8B6DD.7020001@gmx.net> In-Reply-To: <47F8B6DD.7020001@gmx.net> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Hannes Tschofenig wrote: > Hi Henning, > > Henning Schulzrinne wrote: >> There are two kinds of end-user white lists, individual and shared. >> Building individual white lists ("everybody in my address book") is >> relatively straightforward. Building shared address lists ("everybody >> my friends and colleagues have called") requires a bit more work. >> > That's true. The later aspect would go into exploiting your > relationships you have in a social network. Right; that is exactly what I thought as well. But there is a problem. Jagatic et al. [1,2] conducted a study on the effect of social networking on phishing. Their results indicate that 72% of the recipients responded to the phishing email that purported to originate from a friend within their social network, while only 16% of the recipients responded when the phishing email was from an unknown address. So ... if we go the social networking route, does that mean that you become an easier target for phishing attempts by someone pretending to be on your social list? [1] T. Jagatic, N. Johnson, and M. Jakobsson, "Phishing attacks using social networks," manuscript, Indiana University Human Subject study 05-9892 and 05-9893, 2005. [2] T. Jagatic, N. Johnson, M. Jakobsson, and F. Menczer, "Social Phishing," Comm. of the ACM, 50(10), pp. 94-100, October 2007. - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Tue Apr 8 15:23:11 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E20733A6C06; Tue, 8 Apr 2008 15:23:11 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648EF3A6C8D for ; Tue, 8 Apr 2008 15:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.41 X-Spam-Level: X-Spam-Status: No, score=-5.41 tagged_above=-999 required=5 tests=[AWL=1.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-OGfleY4l0T for ; Tue, 8 Apr 2008 15:23:09 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 594593A6B88 for ; Tue, 8 Apr 2008 15:23:09 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2008 15:23:26 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m38MNQiv014388; Tue, 8 Apr 2008 15:23:26 -0700 Received: from dwingwxp01 ([10.32.240.197]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m38MNPPj009929; Tue, 8 Apr 2008 22:23:25 GMT From: "Dan Wing" To: "'Vijay K. Gurbani'" , "'Hannes Tschofenig'" References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F76BCB.1040100@gmx.net> <47F8B6DD.7020001@gmx.net> <47FA25DD.4070406@alcatel-lucent.com> Date: Tue, 8 Apr 2008 15:23:25 -0700 Message-ID: <3ed501c899c7$29e03400$c5f0200a@cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <47FA25DD.4070406@alcatel-lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciYteWuUUlCywmlTy+6ak+zaB1SPwBEO40g DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2137; t=1207693406; x=1208557406; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dwing@cisco.com; z=From:=20=22Dan=20Wing=22=20 |Subject:=20RE=3A=20[Rucus]=20Next=20Steps=20towards=20the= 20EG |Sender:=20; bh=k0ZIJYMX9YCdH0LNoCsNQ0gpFh03B+fU2+NSm9SS8FE=; b=FjmY3tzmpRzJ+j+E3eWI9LjrKyOVQgRi0/8UoKLgfVQ2HR0ZaaadhGYR2Z 59QxzZ95zv4dGbqY/cM5lzNZWVrmA0o7lb5ny8tmd29c4zrKX2izVdbmwDM7 qaKIfYjnp24PiXsJE46hCLtveqNkU1QbHKx/aCDPqpMLbx+7kYxZQ=; Authentication-Results: sj-dkim-1; header.From=dwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org > -----Original Message----- > From: rucus-bounces@ietf.org [mailto:rucus-bounces@ietf.org] > On Behalf Of Vijay K. Gurbani > Sent: Monday, April 07, 2008 6:47 AM > To: Hannes Tschofenig > Cc: rucus@ietf.org > Subject: Re: [Rucus] Next Steps towards the EG > > Hannes Tschofenig wrote: > > Hi Henning, > > > > Henning Schulzrinne wrote: > >> There are two kinds of end-user white lists, individual > and shared. > >> Building individual white lists ("everybody in my address > book") is > >> relatively straightforward. Building shared address lists > ("everybody > >> my friends and colleagues have called") requires a bit more work. > >> > > That's true. The later aspect would go into exploiting your > > relationships you have in a social network. > > Right; that is exactly what I thought as well. But there is a > problem. Jagatic et al. [1,2] conducted a study on the effect of > social networking on phishing. Their results indicate that 72% of > the recipients responded to the phishing email that purported to > originate from a friend within their social network, while only 16% > of the recipients responded when the phishing email was from an > unknown address. > > So ... if we go the social networking route, does that mean that > you become an easier target for phishing attempts by someone > pretending to be on your social list? > > [1] T. Jagatic, N. Johnson, and M. Jakobsson, "Phishing attacks > using social networks," manuscript, Indiana University Human > Subject study 05-9892 and 05-9893, 2005. > [2] T. Jagatic, N. Johnson, M. Jakobsson, and F. Menczer, "Social > Phishing," Comm. of the ACM, 50(10), pp. 94-100, October 2007. I believe I found a brief write-up of that research at http://www.indiana.edu/~phishing/social-network-experiment/ The key is 'proported'; we wouldn't want to do that, and with SIP's strong identity, we wouldn't have messages from a *proported* member of the social circle (but which is actually from a spammer). Rather, we would have a message that is provably from a member of the social circle. -d _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus From rucus-bounces@ietf.org Thu Apr 10 13:12:16 2008 Return-Path: X-Original-To: rucus-archive@ietf.org Delivered-To: ietfarch-rucus-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 692AF28C224; Thu, 10 Apr 2008 13:12:16 -0700 (PDT) X-Original-To: rucus@core3.amsl.com Delivered-To: rucus@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65AD528C504 for ; Thu, 10 Apr 2008 13:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DYR6dLh8PVPX for ; Thu, 10 Apr 2008 13:12:11 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id E006828C4F9 for ; Thu, 10 Apr 2008 13:12:10 -0700 (PDT) Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id m3AKCPwq025429; Thu, 10 Apr 2008 15:12:25 -0500 (CDT) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/8.12.11) with ESMTP id m3AKCPA29289; Thu, 10 Apr 2008 15:12:25 -0500 (CDT) Message-ID: <47FE74A8.7050607@alcatel-lucent.com> Date: Thu, 10 Apr 2008 15:12:24 -0500 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Dan Wing References: <47F29396.9070503@gmx.net> <1a4601c8944c$de7a9520$c5f0200a@cisco.com> <47F76BCB.1040100@gmx.net> <47F8B6DD.7020001@gmx.net> <47FA25DD.4070406@alcatel-lucent.com> <3ed501c899c7$29e03400$c5f0200a@cisco.com> In-Reply-To: <3ed501c899c7$29e03400$c5f0200a@cisco.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: rucus@ietf.org Subject: Re: [Rucus] Next Steps towards the EG X-BeenThere: rucus@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Reducing Unwanted Communication Using SIP \(RUCUS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rucus-bounces@ietf.org Errors-To: rucus-bounces@ietf.org Dan Wing wrote: vkg> So ... if we go the social networking route, does that mean that vkg> you become an easier target for phishing attempts by someone vkg> pretending to be on your social list? vkg> vkg> [1] T. Jagatic, N. Johnson, and M. Jakobsson, "Phishing attacks vkg> using social networks," manuscript, Indiana University Human vkg> Subject study 05-9892 and 05-9893, 2005. vkg> [2] T. Jagatic, N. Johnson, M. Jakobsson, and F. Menczer, "Social vkg> Phishing," Comm. of the ACM, 50(10), pp. 94-100, October 2007. dwing> dwing> I believe I found a brief write-up of that research at dwing> http://www.indiana.edu/~phishing/social-network-experiment/ dwing> dwing> The key is 'proported'; we wouldn't want to do that, and with dwing> SIP's strong identity, we wouldn't have messages from a *proported* dwing> member of the social circle (but which is actually from a spammer). dwing> Rather, we would have a message that is provably from a member of dwing> the social circle. Dan: I am not arguing with what you write above. The fundamental straw that binds this work has to be Identity (modulo the concerns on it that have been expressed by draft-rosenberg-sip-rfc4474-concerns-00 and draft-kaplan-sip-baiting-attack-02). However, my post was in response to what Prof. Schulzrinne described as "Building shared address lists ("everybody my friends and colleagues have called") requires a bit more work." This is the aspect of social networking that is challenging when you consider transitive trust issues in social networks where people are separated from each other by 3 or 4 degrees. For instance, if I have a filter that allows all my colleagues in LinkedIn to contact me, have I opened myself to spit if a tertiary connection gets her identity stolen and spams me? Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} WWW: http://www.alcatel-lucent.com/bell-labs _______________________________________________ Rucus mailing list Rucus@ietf.org https://www.ietf.org/mailman/listinfo/rucus