Subject: [domainrep] Reputation basis of Charter flawed.

From: Douglas Otis <[email-masked]>
Date: Mon, 15 Aug 2011 14:52:40 -0700

The charter attempts to establish reputation schemes based on flawed 
methodologies.

a) SPF may not identify sender domains within shared IP addresses.
b) SPF may invite amplification attacks.
c) DKIM may not identify intended message recipients.
d) DKIM may not prevent a spoofed header from being applied against a 
reputation assertion.

SPF domain reputations are problematic.
----
1) It is common for multiple domains to share a common address.
2) A domain used to reference an "authorized" address within an exchange 
is undefined.
3) Enforcement is problematic because a domain reference might be 
extracted from-
  a) HELO/EHLO
  b) return-path
  c) PRA (From, Sender, Resent-*)
4) SPF macro libraries expand email-address local-parts and permit 
dangerous network amplifications against innocent third-parties that may 
not even be present within an attacking message.

DKIM domain reputations are problematic.
----
1) DKIM may not confirm intended recipients.
2) DKIM permits pre-pended header fields where asserting good a 
reputation could prove hazardous.

Sending commercial/bulk email to recipients that never expressed a 
desire to receive them is often the basis used to describe an act of 
spamming.  Since DKIM permits replay by design, a malefactor could 
utilize this weakness to damage reputations based upon valid DKIM 
signatures.

Several have also expressed a desire to aggregate reputation based upon 
disparate methods.  Such aggregation further reduces any clarity 
regarding why a particular reputation has been asserted, and whether the 
actors involved were controlled by the assessed domain.

Unless SPF is limited exclusively to that of the EHLO domain and DKIM 
confirms the intended recipient, these two methodologies can not be 
safely used.  Imposing such restrictions would permit a class of spam 
that could not affect the reputation of a domain.  For domain reputation 
to work effectively and safely with email, there must be a safe method 
available to authenticate the SMTP transmitter.  To deal with the 
growing use of LSN, a cryptographic technique as enabled by DANE would 
be ideal.

The charter should remove references to flawed SPF and DKIM 
methodologies for establishing reputations.  Refer instead to as yet an 
undefined method.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 15 Aug 2011 15:03:57 -0700

References to DKIM and SPF are merely examples that create the need being addressed here.  The general framework is one that can support developing reputation with any identifier that can be reliably established using whatever method people find useful.

I think including them as use cases is actually a good idea.  Their respective security considerations are already well-documented, and would of course be necessary review for anyone implementing a reputation system based upon them.

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 16 Aug 2011 07:00:55 -0700

On 8/15/2011 3:03 PM, Murray S. Kucherawy wrote:
> References to DKIM and SPF are merely examples that create the need being
> addressed here.

+1

An essential point about this new work is that it /starts/ with a "verified 
domain name" without having to worry about any of the details that made the 
domain name be verified.  How the verification is obtained is out of scope for 
this group.

That is, SPF and DKIM really are just examples of how to produce verification.

If someone has criticisms of the verification process, they need to pursue them 
in a venue that discusses domain name verification.  Domainrep has nothing to do 
with domain name verification, anymore than a TCP design group has anything to 
do with IP design.

Hence, discussion of SPF or DKIM is out of scope for this group.

> The general framework is one that can support developing reputation with any
 > identifier that can be reliably established using whatever method people find
 > useful.

To be precise, I believe it's "domain name identifier" rather than "any 
identifier", for this group.

> I think including them as use cases is actually a good idea.

+1.  It permits designing at a systems level and with an anchor in the real 
world of likely uses.

> Their
> respective security considerations are already well-documented,

For this group, that doesn't matter.  It's out of scope.

The way to keep an out of scope topic out of scope is to avoid /any/ discussion 
of it.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Douglas Otis <[email-masked]>
Date: Tue, 16 Aug 2011 11:55:24 -0700

On 8/16/11 7:00 AM, Dave CROCKER wrote:
> An essential point about this new work is that it /starts/ with a 
> "verified domain name" without having to worry about any of the 
> details that made the domain name be verified.  How the verification 
> is obtained is out of scope for this group.
>
> If someone has criticisms of the verification process, they need to 
> pursue them in a venue that discusses domain name verification.  
> Domainrep has nothing to do with domain name verification, anymore 
> than a TCP design group has anything to do with IP design.
>
> To be precise, I believe it's "domain name identifier" rather than 
> "any identifier", for this group.
>
>
> +1.  It permits designing at a systems level and with an anchor in the 
> real world of likely uses.
>
>> Their
> The way to keep an out of scope topic out of scope is to avoid /any/ 
> discussion of it.

Using SPF or DKIM as examples of domain verification within the repute 
charter indirectly endorses the methods as suitable for use with a 
reputation scheme.  These methods DO NOT verify a domain as controlling 
destination or the act of sending a message.  Hardly a basis for 
reputations even as an example!

When the suitability of a protocol is out-of-scope, a request to have 
the protocols removed from the charter is appropriate.

Only large entities with the might of volume are safe from abuses 
permitted by these two schemes.

Support issues represent a significant cost related to offering reputation.

Aggregation will not avoid accountability.

One should hope the resulting reputation service is suitable for both 
small and large entities.

-Doug