RE: [gnso-ff-pdp-may08] Meeting followup -- "Response Process" conversation

[Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>]

Mike mentioned:

#Here's my (somewhat editorialized) summary of the conversation;
#
#Suggestion -- make the response processes more uniform across the 
#parties, perhaps securing or certifying the information-flows between 
#those entities.

Hypothetically, assume that the minimum required bit of information
for a fastflux report is the name of the potential fastflux domain
(such as yes2-quality-meds.com in the example I just passed along
in an earlier message). 

I'm not clear on what would need to be secured or certified about that
sort of submission.

If someone maliciously (and anonymously) submitted a NON-fastflux domain
as fastflux, such as www.icann.org, it is simple enough to empirically 
test that domain by resolving it, see that it is not acting fluxy, and
then perhaps continue to monitor it for a while for any changes. Since 
no fluxing would be detected, that submission would presumably result 
in a determination that that domain is not FF, and thus no action would 
ensue.

If, on the other hand, a real fastflux domain were to be submitted, again, 
all that you'd need would be the domain name. The registrar receiving 
such a complaint should be able to readily and empirically verify the 
fluxing nature of that domain via the output from DNS, with no further 
narrative or evidential information required. 

Or am I misunderstanding, and the worry is more along the lines of
protecting a reporting party from retaliatory harrassment, perhaps?

If all that's saved is the nominated FQDN, that wouldn't provide much
of a foundation for a disgruntled badguy/badgal to use to track down
and harrass a FF reporting party. (Of course, if a name and email address 
is requested and recorded, perhaps along with the IP of the submitting
host, that changes the exposure of the reporting party a bit, although
things like throw away email addresses and use of anonymous VPN networks
have the potential to substantially limit the privacy risks to reporting 
parties)

#Concern --  be careful about giving new authority to trusted/private 
#entities that are outside the normal process of law, as processes 
#that privilege one group of entities over others can make it easier 
#for those privileged parties to take away the rights of others.

The only authority that would be conveyed would be the ability to 
suggest a domain for evaluation as potentially FF. Finger pointing
is a pretty minor power to grant, given that it only results in a 
extremely lightweight objective test (e.g., resolution of a domain 
name). 

#- Focus process-improvement efforts on existing entities, strive not 
#to create new ones

Since I don't believe any new entity needs to be created, think that's a
fine principle. Skip creating the Department of Fastflux Affairs.

#- Limit security and certification to information-exchange processes, 
#not the data that is exchanged (secure the data-flows, share the data-stores)

Still not clear about what needs to be secured about data flows.

Is the worry that the FQDN being reported will be sniffed?

Or is it that the FQDN will somehow be tampered with en route?

If either of those are the concern, making the submission channel SSL 
encrypted, or allowing PGP signed or encrypted email submissions should 
quash the sniffing or in-flight tampering concerns.

If the worry is that a submission will be "accepted" by a designated
recipient, but then /dev/null'd with no action, a unique ticket number 
(like those currently issued by WDPRS) would allow for followup studies, 
if auditing compliance proved to be necessary or desirable. 

#- Do not imbue private entities with the powers that should be 
#reserved for governments

That could be read by someone (presumably with a Dickensian accent :-))
as, "Please Sir, rather than taking care of this issue ourselves, we'd 
like government regulation or intervention to handle it instead." 

I don't *think* that's what folks want or intend, but I worry that's how 
that statement might end up being construed.

Regards,

Joe 

Disclaimer: all opinions strictly my own.