Minutes for Repute BoF, IETF 81, 25 July 2011

15:10, convene

Murray Kucherawy:
Defines problem space and scope.
   Trying to define extensible mechanism for answering question:
      What is the reputation of some given domain name (or other identifier)?
Reviews status of work so far.
Lists initial I-Ds.
Summarizes charter proposal.

Discussion:

Keith Moore:
   Have had problems with "reputation services" before.
   Hard to fix unfair bad reputation.
   Need reputation service for reputation services?
   Limit to a particular prob space, such as email spam; it affects the
   overall design approach

Nathaniel Borenstein:
   Whom do you trust is indeed a key question.
   Will we some day have "market in trust" ?

John Levine:
   VBR - we went down this road.
   Desires to see plausible use cases.

Jim Fenton:
   Many possible use cases.
   Use case could be reputation of restaurants.

Bob Morgan:
   There's been lots of work in this area before.
   Need to review the prior (failed) work.
   Could something like this be useful for web authentication federations?
   Reputation is (only) one piece of the puzzle.

Johan Pouwelse:
   We've been working on reputation stuff for a long time.
   Have some running code.
   Use case is file sharing.
   Making progress due to being self-organizing, so can scale.
   In this work, typically have a query/response.
   Given available storage, it's better to store and cache lots of info and do
   processing across it all, and cache results.

Matt Lepinski:
   When I read the documents, I have a hard time understanding how we're
   going to get to interoperability.  If I were going to code an application
   that made use of reputation, unless I know how it's going to be created,
   it's difficult for me to know how I should be using this effectively.

Murray:
   Effectively, that's negotiated out of band.  You use the services based on
   *their* reputation.  If they provide bad service to you, you stop using them.

Barry:
   As a consumer of the information, you need to know what the information *means*,
   but not how it was generated.

Matt Lepinski:
   It would be good to have that clarified in the documents.

Dave Crocker:
   Complex space.
   Need to balance.
   Probably best to start with core of email reputation, start using it, then look for
   nearby use cases to extend to (one or two others) -- that'll help drive success.

Keith Moore:
   If reputation service says my address is tainted, and I don't have recourse,
   there's a problem. There needs to be recourse and accountability for reputation
   providers.  Maybe it's not in the protocol, but if it's not considered part of
   the problem, you're creating a mess, and it's dangerous.

Pete Resnick:
   Providing a mechanism for reputation service feedback might be a useful additional doc,
   and might get people to think about how to implement such a thing.

Murray:
   Someone who objects to their own reputation, or feedback into the system that got you
   there in the first place?

Pete Resnick:
   Maybe both.  I'm willing to entertain scope about that.  To Dave's comment
   about sticking to email as a core: the three systems you use as a base
   (DKIM, SPF, Sender-ID) all work on the domain level.  Maybe it's worth
   limiting this at the core to domain level.  It could be infinitely expansible.
   Design consideration should be around domain, and maybe specifically domain
   sending reputation.

Murray:
   Maybe the charter should stop there, and we can recharter to go further.

Dan Druta:
   Governance is a key aspect.
   A reputation can go in any direction; input is not well bounded.
   Categories of sources should be well defined and balanced such that
   a competitor or personal enemy can't ruin someone else's reputation.
   We need to be clear about who's collecting, who's analyzing, who's
   receiving... and we need to have a manual override to prevent abuse
   of the reputation system.

Murray:
   Its hard to know how to do that in a protocol, but we could put this
   sort of stuff in an informational document.

Brian Trammell:
   Protocol should be able to support any governance model you'll see in the real world.
   Protocol should facilitate migration between reputation providers.  We need to make
   sure the values assigned for reputation are portable.  The scale of the numbers needs
   to be defined.

Chris Bonatti:
   Leaving the whole semantic aspect to the side, will amplify issues with reputation
   destroyers out there. What's worked has been to push the complexity to the edges.
   Empower endpoints to be able to make their own assessments.

Murray:
   What we're working on is for example having an end system be able to pool input
   from a bunch of peers, or just get the reputation from a given service.

John Levine:
   Trying to build in accountability is a huge mistake. The bad guys will try hard
   to defeat any feedback system, and we won't be able to detect it.
   There's case law and statues in North America about how this stuff can work.

? from Cisco:
   May need more than just an identifier: sometimes (identifier, service).
   Do you trust this identifier for file sharing, for email, for malware, or whatever?

Dave Crocker:
   The group should consider mechanisms for which there's existing practice, and
   therefore some pragmatic basis for knowing its strengths and weaknesses.
   Reputation should do a "diagram" similar to the one that DKIM eventually did.

--- Question from the chair ---

We've discussed scope and problem statement.  Is the proposed scope well enough
understood?  Are there further comments on the scope?

Eric Osterweil:
   I heard three different things about scope: self-organizing, push it to the edge,
   and service providers.  Those are all very different, and the scope should specify
   whether you're choosing one of those, or not choosing.  The protocol you design for
   a self-organizing system will probably not suit a large service provider.  The
   protocol should also allow the client to ask "Why?"

Lucy Lynch:
   I understand the scope to be how to build a reputation and how to report it and
   get it consumed, but not what to do with it once it's consumed, and nothing about
   redaction.  I believe that's a reasonable scope.

Keith Moore:
   Doing this just for email is probably good enough for now.

Murray:
   If we focus on email, may throw away some of the generality.

--- Further questions from the chair ---

Who's willing to work on writing docs?
   About 8 people raised hands.

Who else is willing to review in timely manner and actively participate?
   A handful of hands, but not terribly many.

---

Thanks to Jeff Hodges for taking notes!

16:10, adjourn