Re: [gnso-ff-pdp-may08] DTeam - framework for proposal

[Marc Perkel <marc@xxxxxxxxxx>]

Good work Dave in laying this out. Just for the record I see the debate 
as a spirited discussion. People have laid their ideas/concerns out on 
the table and now we can start unifying on common ground.
Dave Piscitello wrote:
> It occurred to me that we have had numerous, valuable threads 
> regarding solutions, and many expressions of concerns of scope, cost, 
> impact. These are all good activities.
> What we may be missing among all these is a framework for what any 
> resulting (set of) solutions we recommend would be 
> deployed/implemented and by whom.
> In an admittedly simplistic fashion, I think the following is a 
> strawman for a multi-organizational approach to "combating fast flux" 
> that could be applied to future attacks and abuses
>     * quantify the attack. We are slowly teasing out the
>       characteristics we use to identify a fast flux network based in
>       input from Joe, me, Greg, Randy, Eric, Mark and others. This
>       effort also helps us identify the data required to quantify the
>       attack. This answers the question, "What is it that we want to
>       detect?"
My thinking is that if information about fluxing and whois type 
information (as outlined in previous messages( is made available through 
DNS then filtering services can identify an attack. We can also 
distinguish between fraud and free speech and report only the fraud 
based use of fast flux and protect free speech uses of fast flux. The 
difference being that fraud based fast flux has a spam component driving 
it that is easilly identifiable. (Spam pretending to be banks and 
PayPal) So free speech wouldn't be falsely identified.
>    *
>
>
>
>     * develop a methodology/tool that has a very high probability of
>       detecting the attack and a very low probability of reporting a
>       false positive (Joe's tool, TMF, etc. are examples of detection
>       methods and tools). This answers the question, "How can we
>       detect it?"
Agreed.
>    *
>
>
>
>     * identify the data collectors. Marc and others have identified
>       various sources of data and perhaps it would be helpful to
>       identify the parties (e.g., registrars and registries) who
>       collect it. This answers the question, "Who can provide the data
>       we need to detect it?"
Yes - generally any competent spam filtering operation would be in a 
position to gather and report data to registrars. And with a common set 
of tools this can be much easier to get people on board and reporting it 
in a useful manner.
>     * identify the approved users of the data. The range of users
>       spans from "anyone with an internet connection" to "parties who
>       are trusted to use the data". For the sake of this strawman,
>       let's go with the trusted party end of this spectrum. This
>       answers the question, "Who is responsible for detecting it?"
Trusted parties would be people who are receiving a large amount of 
email that contains spam point to phishing sites on FF networks. The 
operations would install software tools for detecting and reporting 
phishing. Spam filtering companies and large operations like Yahoo, 
Google, Hotmail etc would be included. Inclusion would be based on:
1) Data - people who are processing email in sufficient volume to be 
interesting.
2) Competence - able to install detction and reporting software.
3) Accuracy - reporters who have a high level of false positives would 
be excluded.
Those who would be excluded.

1) Government agencies who might use the system to uppress free speech.
2) The general public - people who would just create noise in the 
system, and spammers who would game the system.
3) Reporters who get too many false positives.

Keep in mind - this is not a shadow government to secretly control the 
internet. This is just a way to make fraud detection efficient and 
accurate. And I stress accurate.
>     * identify the "trust model" for approved data users. We want a
>       high confidence that the parties will act in the best interests
>       of the community at large, for users and registrants. This
>       answers the question, "Why do we entrust these individuals to
>       detect it?"
With good tools this could be fairly easy. Might be like other spam 
filtering operations that coordinate data on the Internet. Someone 
throws up a .org and has a sign up process. They start sending data and 
if the data is good then their electronic reputation increases until 
they hit a level where their data is mixed in.
>     * identify the access and reporting model for the approved data
>       users. We have proposals ranging from publishing additional
>       information via the DNS using TXT records to SSL gateway portals
>       that provide WDPRS reporting like capabilities. This answers the
>       questions, "How do the trusted parties acquire data they need,
>       and report abuse?", "How do we keep the data from falling into
>       the hands of folks who would misuse the data?", and "How do we
>       keep bad actors from disrupting the access method?"
I'm assuming the data would be reported to the registrar responsible for 
the reported domain. If the report is about example.com and that is 
registered with godaddy.com then GoDaddy would receive the reports. I 
would use standard email (SSL) and ARF (modified) format and forward the 
phish to them. Their mailbox would oble receive emails from a white list 
based on the Forward Confirmed RDNS of the sending host. (example: 
*.junkemailfilter.com)
>     * identify the responders and the response. In several models,
>       we've discussed accelerated suspension of domains by registrars
>       and registries, with processes for reinstatement, etc.
The idea here is that (I believe) most FF fraud abuse is very easily 
identifiable and that 90% of it can probably be identified with 100% 
accuracy. (The other 10% might take more work and have to be looked at 
manually). The idea being that the high accuracy process be used for 
automated takedown. If this results in false positives then the system 
will be adjusted to fix that. The registrars would control the takedown 
process with whatever methods work for them. I would hope that 
registrars work together cooperatively (rather than competitively) on 
this so that they develop common tools and procedures so they all 
benefit from solving a common problem.
> If we were to lay out a proposal in this fashion, I think we could 
> then discuss pros/cons more objectively. We might even be able to add 
> clarity to issues that make some folks uncomfortable so that the 
> proposal addresses (or at least offers) sufficient checks and balances 
> to hopefully make everyone comfortable with what we recommend to the GNSO.
I think so. We might also break some issues up into stand alone pieces. 
Sort of building blocks that we can all agree on. For example, providing 
dat through DNS to help us on the edges ID fraud. If we can agree on 
that then that's a useful piece. Establishing a common abuse reporting 
system so that those of us who detect problems can inform those who can 
fix the problems. And do it with automation. That involves creating 
reporting standards that everyone agrees on.
> Hope this helps.
Yes Dave - it does help.