Early Review of draft-ietf-repute-considerations-02
review-ietf-repute-considerations-02-secdir-early-waltermire-2013-09-26-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document
 editors and WG chairs should treat these comments just like any other last
 call comments.



This draft discusses considerations for providers and consumers of reputation
data systems targeted at traffic sources. This draft focuses primarily on email
reputation systems, but provides guidance that is generally applicable to other
 traffic sources.



After reviewing this informational document I have a few nits and some minor
security-related concerns. This document is not ready as there are a few points
that need to be addressed.



Areas of concern:



Since reputation data is tied to identifiable traffic sources, should there be
privacy considerations discussed in this document?



Section 1: Introduction, Paragraph 1: The last sentence refers to “several
operational concepts appear to be common to all of these”, but it is not clear
what “common to all of these” means.  Rating methods? Services? Problem domains?
 Something else?



Section 3: Evolution, Paragraph 3:



There is no evidence presented to justify the claim that the problem space is
reduced by focusing on good actors as compared to bad actors. The author makes
the claim that there are “vastly more IP addresses and email addresses used
 by bad actors to generate problematic traffic than are used by good actors to
 generate desirable traffic.” I’d like to see some statistics from one or more
 reputable studies (no humor intended) that defend this perspective.



There is discussion that “manually edited whitelists” have shown some promising
results. It doesn’t seem like this will scale well in the face of the larger
IPv6 address space and new GTLDs. Some discussion on this would be useful.



Section 4: Reputation Clients:



The text “For operational clients, this should prompt balanced and comparative,
rather than unilateral, use of the service” is confusing. I believe this is
recommending to use multiple services in a balanced and comparative approach
 instead of using a single service, but it doesn’t read this way.



Section 5: Reputation Service Providers:



In paragraph 1 the text references “answer as many of the questions identified
in

Section 4

 as possible”, but it is not clear what the referenced “questions” are.



In paragraph 3 the text asserts that “Reputations should be based on accurate
identifiers, i.e., some property of the content under analysis that is
difficult to falsify.” Is there a general litmus test that can be applied here?
Human
 verification? Automatable verification mechanisms? Is there a minimum
 suggested/required practice?



Section 6: Security Considerations:



While the statement in this section is true, the document doesn’t introduce any
new security issues, I was hoping for a summary of the security issues
discussed in the earlier subject matter with suggestions of security mechanisms
that
 should be considered for use to address these concerns.



Some examples:

·



Discuss using mechanisms to authenticate RSP services and to provide integrity
and confidentiality over exchanged data. Is there a need for mutual
authentication of clients and servers?

·



The case in Section 4, paragraph 2 is a significant security consideration.
Discuss communication mechanisms that enable RSPs to communicate end-of-life
for their services to differentiate from malicious activity. Could this be
 handled using DNS SRV records? If the service is no longer announced, this
 could signal end-of-life for the service. If this is too specific for the
 scope of the document, a more general discussion could be included describing
 the characteristics of any acceptable solution.



A few nits:



Abstract:

s/reputation systems is has become/reputation systems has become/



Section 4: Reputation Clients:

s/whether the reported reputation a scalar/whether the reported reputation is a
scalar/

s/capability to effect local overrides/capability to affect local overrides/

s/One choice is to query and cross-referencing multiple RSPs/One choice is to
query and cross-reference multiple RSPs/



Section 5: Reputation Service Providers

s/found in a validated domain-level signature is./found in a validated
domain-level signature is verifiable./

s/For example, it shoudl be possible for the reply to/For example, it should be
possible for the reply to/