Re: Email Web of Trust - Defining the metrics

At 12:40 PM 3/16/2004, Yakov Shafranovich wrote:
>Mark Baugher wrote:
>>Yakov,
>>    I think we should try to capture the antispam counters as SNMP 
>> Management Information objects (SMIv2), we should define access to these 
>> counters using SNMPv3, and we should consider shortcomings and 
>> alternatives to SMIv2 and to SNMPv3.  For example, can IPsec be used for 
>> providing privacy and antidos as well as confidentiality and integrity 
>> to SNMP protocol operations?  Is the SNMP management information (SMI) 
>> definition suitable for what we need or are there better ways to 
>> represent the information?
>
>IMHO, I think we should first define what types of counters we are 
>including and then how they are represented. This split can help us 
>evaluate the benefit vs. cost of the idea itself separate from 
>implementation details.

Regarding "implementation details," I think that use of SNMP is more than 
an implementation detail because it entails a certain model that may or may 
not be what we want for a reputation service.  SNMP v1/2 have a 
management-application to managed-entity model of interaction, for example, 
and some types of management data can be represented easily while others 
cannot.  SNMPv3 also has a security model that may or may not meet the 
needs of a reputation service.  We should definitely look into it and treat 
it as a strawman approach that lets people experiment, critique, and maybe 
even reject following analysis and experience.

Regarding the counters, I think this is something that the entire subgroup 
needs to participate in and contribute to.  If it were up to me, I would 
have two classes of counters, one for the mail that the relay flagged as 
"probably spam" and the second class of counters would be for mail that the 
user rejected as "spam."  This is probably naive.  And it assumes that 
there is some authenticated means for a user agent to communicate the 
disposition of a message to a designated MTA.

There are probably other objects appropriate for an "antispam MIB" that 
have nothing to do with reputation such as counts of messages labelled as 
"probably forged."


>>   This work should come after a description of one or two applications 
>> that can use the counters such as a trusted reputation service.  I 
>> expect we would undertake this work only if we are sure that it can 
>> support a trusted reputation service using, for example, a web of trust 
>> model where members trust other members to maintain counter integrity.
>
>Agreed. We will also need to elaborate why this would be useful to helping 
>fight spam, and the various costs and benefits involved.

ok.


>>   This work could be considered as a formal RG work item and intended to 
>> be published as an Experimental RFC (such RGs publish on Experimental or 
>> Informational RFCs).  I would be willing to author or co-author the 
>> document.  I have previously done an SNMPv1 MIB using an SMIv2 compiler, 
>> http://www.ietf.org/rfc/rfc2959.txt
>
>This is an IRTF group so we don't really have formal work items. If you 
>put together a document that documents discussions in this subgroup, and 
>this subgroup agrees with the fact that the document can be associated 
>with it, then it an be published as a formal ASRG document. Also, 
>consensus is not required unlike the IETF, there can be several competing 
>documents at any given time. Of course, both John and myself still have to 
>approve that draft and send it over to the ID administrator.

ok.


>But I think you can go ahead and put together a draft about counters. I 
>still think personally that we should distinctly split the actual idea 
>from a possible implementation via SNMP. Perhaps, we should lay out one 
>section with the counters, the idea itself and arguments; and a separate 
>section listing a possible implementation via SNMP.

I'm fine with this if some other people are willing to contribute.  Several 
postings to this thread tell me that several people are at least thinking 
about this problem.

Mark


>Yakov
>
>Yakov