Re: Email Web of Trust - Defining the metrics

At 10:17 AM 3/17/2004, Alan DeKok wrote:
>Mark Baugher <[email protected]> wrote:
> >     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.
>
>   I agree.  Having a standard for recording such information means
>that it's easier to exchange data, and to talk about that data.
>
> > For example, can IPsec be used for providing privacy and antidos as
> > well as confidentiality and integrity to SNMP protocol operations?
>
>   I would start off by defining what data needs to be recorded, and
>worry about publication/exchange of that data later.

Here is what I have gleaned from a few notes posted to this list.
1. count messages accepted from a source by the MTA
2. count messages accepted from a source by the MUA
3. count messages identified as spam from a source by the MTA
4. count messages rejected as spam from a source by the MUA

The model is that the MTA is maintaining counters of actions that
it takes upon receipt of a message and is maintaining counters of
actions that an MUA takes in response to mail that it forwards to
the MUA.  The protocol for this reporting is not yet defined, but
I'd expect that some authentication requirement is needed.


> > Is the SNMP management information (SMI) definition suitable for
> > what we need or are there better ways to represent the information?
>
>   SNMP is probably sufficient.

I can imagine using SNMP to fetch the data and manage the MTA.  This
does not scale to large numbers of peers since it would burden the
MTA with a plethora of SNMP get requests.  So after the data is fetched,
it can be disseminated in a variety of ways and authenticated (e.g.
http://www.cl.cam.ac.uk/ftp/users/rja14/wax.ps.gz )


> >    This work should come after a description of one or two applications
> > that can use the counters such as a trusted reputation service.
>
>   I would turn that around.  Once you define the foundation of a
>service (what it's measuring), it's possible then, and only then, to
>describe how that services uses that data.
>
> >   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.
>
>   A system should be immune to attacks on the counters.  At the
>minimum, if everyone maintains their own counters, you know how much
>you can trust the data.

I think there are two concerns.  One is how well the counter is implemented
according to the natural-language specification.  This will vary between
implementations but there should be a standard reference implementation.
I don't know if there is a mail mib reference implementation but it is
a draft standard so there is likely one out there.

The second concern is the integrity of the counters against subversion
and attack.


> >    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
>
>   Sounds good to me.

How would you proceed?  I was going to just start on a MIB document but I
think Yakov might like to see a counter list as a separate document, possibly
accompanied with some discussion for how the counters can be maintained,
accessed and used.

Mark


>   Alan DeKok.