Early Review of draft-ietf-repute-considerations-02

Request Review of draft-ietf-repute-considerations
Requested rev. no specific revision (document currently at 03)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2013-09-26
Requested 2013-08-08
Authors Murray Kucherawy
Draft last updated 2013-09-26
Completed reviews Secdir Early review of -02 by David Waltermire (diff)
Assignment Reviewer David Waltermire 
State Completed
Review review-ietf-repute-considerations-02-secdir-early-waltermire-2013-09-26
Reviewed rev. 02 (document currently at 03)
Review result Has Issues
Review completed: 2013-09-26


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


A few nits:



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/