Subject: [domainrep] Charter going to the IESG

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 6 Sep 2011 15:15:47 -0700

Hi all,

Some further charter adjustment has been made in conversation with the advising AD, potential co-chairs, Nathaniel and myself.  The latest version is attached.  It is substantively the same as what you've already seen but nails down a few points while sticking to the feedback that's been sent to the list recently.

It would help the cause if, once again, people gave it a once-over and indicated they read this particular version, and made some indication of what role they intend to play as the work progresses (document editor, document reviewer, co-chair, implementer, etc.).  The IESG will be discussing it on Thursday (two days from now) so it's important to get as much of such feedback as is possible by then.

I remain dedicated to being in any or all of those roles except for co-chair, since I'm too close to the material to be able to be effective in that role.

Thanks for your patience as the process rumbles along.

-MSK

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Sep 2011 22:13:02 -0400

>From the subscribed address this time: I have read this.  Like the
previous drafts, I am ok with it.  I plan to review things.  (I am not
at all convinced that the DNS is a good fit for this, and I have
particular reservations about the mechanism proposed, but I think that
is a discussion for the WG to have once it has a charter.  That topic
should definitely be in.)

A

> Working Group Name:
> 	Reputation Services (REPUTE)
> 
> IETF Area:
> 	Applications Area
> 
> Chair(s):
> 	TBD
> 
> Applications Area Director(s):
> 	Pete Resnick <[email-masked]>
> 	Peter Saint-Andre <[email-masked]>
> 
> Applications Area Advisor:
> 	Pete Resnick <[email-masked]>
> 
> Mailing Lists:
> 	General Discussion: [email-masked]
> 	To Subscribe:	    https://www.ietf.org/mailman/listinfo/repute
> 	Archive:	    http://www.ietf.org/mail-archive/web/repute/
> 
> Description of Working Group:
> 	In the open Internet, making a meaningful choice about the handling
> 	of content requires an assessment of its safety or "trustworthiness".
> 	This is based on a trust metric for the owner (identity) of an
> 	identifier associated with the content, to distinguish (likely)
> 	good actors from bad actors.  The generic term for such information
> 	is "reputation".  This working group will develop mechanisms for
> 	reputation reporting by independent services.  One mechanism will be
> 	for a basic assessment of trustworthiness.  Another will provide a
> 	range of attribute/value data that is used as input to such an
> 	assessment.  Each service determines the attributes it reports.
> 
> 	Various mechanisms have been developed for associating a verified
> 	identifier with email content, such as with SPF (RFC4408) and DKIM
> 	(RFC4871).  An existing reputation query mechanism is
> 	Vouch-by-Reference (RFC5518). It provides a simple Boolean
> 	response concerning a domain name used for email.  The current working
> 	group effort will expand upon this, to support additional
> 	applications -- such as Web pages and hosts -- and a wider range of
> 	reporting information.
> 
> 	Given the recent adoption of domain name verification for email,
> 	by SPF and DKIM, the most obvious initial use case for reputation is
> 	for email.  Inbound email filters that perform message authentication
> 	can obtain a verified domain name and then consult a reputation service
> 	provider to make a determination (perhaps also based on other
> 	factors) of whether or not the content is desirable and take
> 	appropriate action with respect to delivery, routing or rejection.
> 	
> 	Another possible use case is identity-based evaluation of web
> 	content using technologies such as the DKIM-derived DOSETA
> 	(work in progress).
> 
> 	This working group will produce specifications for:
> 
> 	   * the detailed requirements for reporting
> 
> 	   * an end-to-end system architecture in which reporting occurs
> 
> 	   * the mechanisms and formats for reporting
> 
> 	Two mechanisms are under consideration:
> 
> 	   * simple -- a reputation is expressed in a simple manner,
> 	               via records in the DNS
> 		       (see draft-kucherawy-reputation-query-dns)
> 
> 	   * extended -- a response can contain more complex information
> 		         useful to an assessor, reported over HTTP using
> 	                 an encoding such as XML or JSON
> 		         (see draft-kucherawy-reputation-query-http)
> 
> 	The syntactic and semantic aspects of mechanisms and formats will be
> 	designed to be application-independent and portable (i.e., reputation
> 	provider-independent).  By distinguishing reporting information
> 	(format) from reporting mechanism (channel), the specifications
> 	will permit adaptation to support reporting through additional
> 	channels.  Limited application-specific tailoring will be
> 	provided for email, to demonstrate the approach, which can be
> 	applied for supportting additional applications.  The design and
> 	specification will also permit adaptation to support reporting
> 	through additional transport channels.
> 
> 	Items that are specifically out of scope for this work:
> 
> 	   * Specific actions to be taken in response to a reputation reply.
> 	     It is up to assessors (i.e., the consumers of reputation data)
> 	     to determine this.  Non-normative illustrations, however, can
>              be included to demonstrate possible uses of reputation data
> 	     in a particular context.
> 
> 	   * Selection of what data might be valid as the subject of a
> 	     reputation query.  It is up to reputation service providers and
> 	     assessors to select which qualities of a body of data might
> 	     be useful input to reputation evaluation.
> 
> 	   * Concerns about methods of verifying domain names that are used
> 	     for email reputation.  A verified domain name is a starting point
> 	     for this work; the means by which it was obtained and the
> 	     "meaning" of the name or its verification are matters for
> 	     discussion elsewhere.
> 
> 	   * Algorithms to be applied to aggregated feedback in order to
> 	     compute reputations.  These are part of a back-end system, usually
> 	     proprietary, and not appropriate for specification as part of
> 	     a query/reply framework and protocol.
> 
> 	The initial draft set:
> 		draft-kucherawy-reputation-model
> 		draft-kucherawy-reputation-media-type
> 		draft-kucherawy-reputation-query-http
> 		draft-kucherawy-reputation-query-dns
> 		draft-kucherawy-reputation-query-udp
> 		draft-kucherawy-reputation-vocab-identity
> 
> Goals and Milestones:
> 	Mar 2012:	Informational document, defining the problem space
> 			and solution architecture, to the IESG for publication.
> 
> 	Mar 2012:	Specification for the multi-attribute reporting
> 			data structure, to the IESG for publication.
> 
> 	May 2012:	Informational document, defining the vocabulary
> 			for providing reputation in the email sphere, to the
> 			IESG for publication.
> 
> 	Jul 2012:  	Specification defining the simple
> 			query mechanism, to the IESG for publication.
> 
> 	Jul 2012:  	Specification for the extended
> 			query mechanism, to the IESG for publication.
> 
> 	Oct 2012:  	Informational document, discussing issues
> 			of data transparency, redress, meta-reputation
> 			and other important operational considerations, to the
> 			IESG for publication.

> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep

-- 
Andrew Sullivan
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 06 Sep 2011 20:45:50 -0700

On 9/6/2011 7:13 PM, Andrew Sullivan wrote:
> previous drafts, I am ok with it.  I plan to review things.

Excellent.

> (I am not
> at all convinced that the DNS is a good fit for this,

And yet I believe you have heard of the RBL and know of its importance to 
anti-spam operations.  Given it's history, what's the problem with the 'fit'?

> and I have
> particular reservations about the mechanism proposed,

Formally, there are two, one for the quick-answer mode and another for the more 
extensive query and answer.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Sep 2011 07:36:48 -0400

On Tue, Sep 06, 2011 at 08:45:50PM -0700, Dave CROCKER wrote:

> And yet I believe you have heard of the RBL and know of its
> importance to anti-spam operations.  Given it's history, what's the
> problem with the 'fit'?

Since we don't have a charter yet, I'm not sure that now's the time to
debate this.  But briefly: 

RBLs use the DNS differently to express their data.  (That particular
approach also has problems, as discussed in the past, but never mind
that.)

The basic problem seems to be that the current approach wants to use
the DNS as the transport for metadata about the DNS itself, and the
reasoning for certain choices in the existing draft boils down to a
complaint about the way the DNS works as actually deployed.  If you
can't get the DNS to do what you want without abusing its design,
that's an indication that maybe it doesn't do what you need after all.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 07 Sep 2011 14:24:28 +0200

On 9/7/11 12:15 AM, Murray S. Kucherawy wrote:
>
> Hi all,
>
> Some further charter adjustment has been made in conversation with the 
> advising AD, potential co-chairs, Nathaniel and myself.  The latest 
> version is attached.  It is substantively the same as what you've 
> already seen but nails down a few points while sticking to the 
> feedback that's been sent to the list recently.
>
> It would help the cause if, once again, people gave it a once-over and 
> indicated they read this particular version, and made some indication 
> of what role they intend to play as the work progresses (document 
> editor, document reviewer, co-chair, implementer, etc.).  The IESG 
> will be discussing it on Thursday (two days from now) so it's 
> important to get as much of such feedback as is possible by then.
>
> I remain dedicated to being in any or all of those roles except for 
> co-chair, since I'm too close to the material to be able to be 
> effective in that role.
>

Charter OK. Available for review and/or document editor.

/rolf

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Sep 2011 06:24:35 -0700

Andrew,

> approach also has problems, as discussed in the past, but never mind

The comparison wasn't meant to be precise to the level of formats, but about the 
basic model.  You are expressing a very basic concern and, so, I was offering a 
very basic comparison that seems to me to counter your concern.

> the DNS as the transport for metadata about the DNS itself,

I don't understand.

>  and the
> complaint about the way the DNS works as actually deployed.

I don't understand.

> If you

What, in particular, is an "abuse" of the DNS' design?

As I understand the current draft specifications, they call upon techniques that 
are already in production use and for a type of service that is not merely "in 
use" but is in fact already essential to the conduct of a massively popular 
Internet service.

Since your concern appears to be about the fundamentals of the proposed work, 
I'm seeking explanation in enough detail to permit serious evaluation of your 
concern.

d/

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Sep 2011 09:43:11 -0400

> >the DNS as the transport for metadata about the DNS itself,

Yes, I know, but I've been unable to figure out over time whether that
is out of willfullness on your part or out of my failure to explain it
clearly enough.  Or, perhaps, both.

Nevertheless, as I already suggested, I would prefer to wait for the
charter before having more debates about substance, because in my
experience such disagreements about the substance can sometimes be
misconstrued as disagreements about whether the very topic ought to be
considered.  To be explicit, I argue that the topic should be
on-charter even if I have reservations about actually doing what is
implied in the charter item.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 07 Sep 2011 07:19:21 -0700

> clearly enough.  Or, perhaps, both.

I was soliciting explanation.  You gave a terse tag line and I'm asking for more 
detail.

I believe one of the continuing sources of dissonance in the IETF is the 
tendency to utter labels or catch phrases rather than offering the underlying 
detail.  Since one listener's interpretation of those labels and phrases is 
often quite different from the speaker's, the exchange begins with a lack of 
shared reference.  I'm asking for enough detail to permit shared reference.

> charter before having more debates about substance, because in my

Again, I don't understand.  The thing being circulated /is/ the charter that is 
being submitted to the IESG.

> implied in the charter item.

What you expressed sounded like fundamental concerns to me.  That makes them 
worth understanding earlier, rather than later.

d/

-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Wed, 07 Sep 2011 11:44:17 -0700

At 15:15 06-09-2011, Murray S. Kucherawy wrote:
>Some further charter adjustment has been made in conversation with 
>the advising AD,

The proposed charter looks fine.

>It would help the cause if, once again, people gave it a once-over 
>and indicated they read this particular version, and made some 
>indication of what role they intend to play as the work progresses 
>(document editor, document reviewer, co-chair, implementer, 
>etc.).  The IESG will be discussing it on Thursday (two days from 
>now) so it's important to get as much of such feedback as is possible by then.

I'll do some reviews.  It's likely that I may implement some of the 
specifications.  I am open to being document editor.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Wed, 07 Sep 2011 17:18:08 -0700

On 9/6/11 3:15 PM, Murray S. Kucherawy wrote:
> version is attached. It is substantively the same as what you’ve 
> feedback that’s been sent to the list recently.
>
Murray,

Based upon methods suggested in the charter, reputations created are 
likely to cause problems where those hosting the name reputation service 
will be held accountable. As was said in the past and on the MAAWG 
mailing list, this charter starts out making misstatements that go to 
the heart of the concern.

"Various mechanisms have been developed for associating a verified 
identifier with email content, such as with SPF (RFC4408) and DKIM 
(RFC4871). ... Given the recent adoption of domain name verification for 
email, by SPF and DKIM, the most obvious initial use case for reputation 
is for email."

When reputation of a name is at stake, the verified role in any 
purported misdeed is critical. While SPF may provide authorization for 
an outbound MTA, it may not verify a domain's involvement with specific 
exchanges from a shared MTA. Also spam is often identified by receipt of 
unsolicited commercial messages but DKIM may not verify a domain's role 
in selecting a recipient since DKIM does not extend to this parameter. 
Ignoring such cases would creates a sizable category for spammers to 
either exploit or abuse.

There also remains the issue related with SPF which could damage DNS by 
leveraging macro expansion of email address local-parts.

Before this effort starts, where all but the largest email providers are 
likely to be unaffected simply because size, a scheme is needed to 
verify the domain managing outbound MTAs. It should be those managing 
MTAs who identify entities using their service and not their recipients 
using risky and unscalable methods. Perhaps DANE and some SMTP auth 
extension might be able to identify outbound MTAs in a manner that 
safely scales and ensures fair reputation assessments. Despite good 
intentions, attempting to leverage methods poorly suited for 
establishing reputation is likely to create problems difficult to later 
remedy.

-Doug

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Sep 2011 21:02:55 -0400

Doug,

On Wed, Sep 07, 2011 at 05:18:08PM -0700, Douglas Otis wrote:

> Before this effort starts, where all but the largest email providers
> are likely to be unaffected simply because size, a scheme is needed
> to verify the domain managing outbound MTAs. It should be those
> managing MTAs who identify entities using their service and not
> their recipients using risky and unscalable methods. Perhaps DANE
> and some SMTP auth extension might be able to identify outbound MTAs
> in a manner that safely scales and ensures fair reputation
> assessments. Despite good intentions, attempting to leverage methods
> poorly suited for establishing reputation is likely to create
> problems difficult to later remedy.

The above suggests to me that, regardless of the foundation statements
in the proposed charter to which you take exception, you still think
that the work is correctly bounded and that these issues would be the
proper purview of a WG in this area.  Am I misreading you?  If so,
please state exactly how.  If not, then I would like to suggest your
message actually supports the charter, even if you think that all of
the initial drafts ought to be changed dramatically in respect of
their substance.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Wed, 07 Sep 2011 18:34:09 -0700

> the initial drafts ought to be changed dramatically in respect of
There are two separate issues improperly combined in the charter.  The 
incorrect assumption of domain validation by either SPF or DKIM to 
assess accountability and then the reputation service itself.   I think 
you also raised concerns regarding suitability of protocols used in 
conjunction with the reputation service.  These validation methods may 
damage DNS and may mis-identify purported actors assessed by the 
reputation service.   With the charter making misleading statements 
regarding the suitability of the "validating" methods, and then 
declaring the basis of the reputation service out-of-scope ensures a 
flawed outcome.  I had asked that these statements in the charter be 
removed and that the validation issue be addressed elsewhere where it 
can be properly discussed.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 09 Sep 2011 13:53:36 -0700

On 9/7/2011 6:34 PM, Douglas Otis wrote:
> There are two separate issues improperly combined in the charter. The incorrect
> assumption of domain validation by either SPF or DKIM to assess accountability
> and then the reputation service itself.

Doug,

Over quite few months and in many different fora, you have constantly been 
citing your concerns about use and discussion of SPF and DKIM.  My own 
perception is that you criticize them every time they are referenced on any and 
every list you monitor.  Such a pattern tends to create an uncomfortable tone 
for public discussion.  In fact it comes quite close to looking like a denial of 
service attack on any group that commits the sin of mentioning SPF or DKIM.

As you note above, validation of an identifier is separate from its use.  The 
Repute working group draft charter, and the work planned for this group, take an 
identifier as input, independent of the method use for its validation.  SPF and 
DKIM are cited as exemplars for verification because, unlike you, the rest of 
the industry considers them useful.

However let's be clear about a key point:  the work of this new group doe not 
depend on SPF or DKIM.  Again: they are merely cited as examples.

Hence, details and concerns about SPF and DKIM are out of scope for this 
domainrep mailing list.

Please refrain from further repetition of your concerns about them on this list.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Sep 2011 12:22:15 -0700

On 9/9/11 1:53 PM, Dave CROCKER wrote:
> > On 9/7/11 6:02 PM, Andrew Sullivan wrote: There are two separate
> > issues improperly combined in the charter. The incorrect assumption
> > of domain validation by either SPF or DKIM to assess
> > accountability and then the reputation service itself.
>  Doug,
>
>  Over quite few months and in many different fora, you have constantly
>  been citing your concerns about use and discussion of SPF and DKIM.
>  My own perception is that you criticize them every time they are
>  referenced on any and every list you monitor. Such a pattern tends
>  to create an uncomfortable tone for public discussion. In fact it
>  comes quite close to looking like a denial of service attack on any
>  group that commits the sin of mentioning SPF or DKIM.

Dave,

The 50 messages sent to this list and the one to MAAWG's technical list 
over more than a year's time can not be described as a DoS, especially 
when 39 were not about the suitability of SPF or DKIM .  Only recently 
during discussions of the charter of the last month has this issue been 
raised 5 times due to real security concerns.  You are also conflating 
anti-phishing concerns related to valid DKIM results returned for 
messages having multiple singleton headers.  That is another topic where 
security was also ignored.

SPF's authorization of an IP address does not verify or "authenticate" 
the domain responsible for sending a message.  A signature that covers a 
message's body may not authenticate the domain responsible for sending 
the message to a specific recipient.  When discussing a protocol aimed 
at blocking domains, authentication of a domain's role in any negative 
assessment is _critical_.

The charter does MORE than suggest example protocols, it misrepresents 
their function:
,--
"Various mechanisms have been developed for associating a _verified_ 
identifier with email content, such as with SPF (RFC4408) and DKIM 
(RFC4871)." ... "Given the recent adoption of domain name _verification_ 
for email, by SPF and DKIM, the most obvious initial use case for 
reputation is for email."
'--

In the past proponents of SPF often misrepresented authorization as 
"authenticating" the sending domain.  Now the Repute charter continues 
this tradition.  Neither SPF nor DKIM "authenticate" OR "validate" the 
domain responsible for sending a message.  This is critical.  A mistake 
as to which domain played a role in sending a message can create a REAL 
DoS for an entire domain well beyond their control.

>  As you note above, validation of an identifier is separate from its
>  use. The Repute working group draft charter, and the work planned
>  for this group, take an identifier as input, independent of the
>  method use for its validation. SPF and DKIM are cited as exemplars
>  for verification because, unlike you, the rest of the industry
>  considers them useful.
>
>  However let's be clear about a key point: the work of this new group
>  doe not depend on SPF or DKIM. Again: they are merely cited as
>  examples.

These protocols are not merely stated as examples, their function is 
described as offering validation suitable for reputation assessment 
based upon the domain.

>  Hence, details and concerns about SPF and DKIM are out of scope for
>  this domainrep mailing list.
>

Removal of erroneous statements from the charter would also eliminate 
this discussion.  Don't start this effort based upon flawed concepts.  
Even those willing to make such a mistake of depending upon bad 
assumptions should not be endorsed in the charter, which is currently 
under discussion on this list.

-Doug

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 12 Sep 2011 15:31:06 -0400

On Mon, 12 Sep 2011 12:22:15 -0700
Douglas Otis <[email-masked]> wrote:

> A signature that covers a message's body may not authenticate the
> domain responsible for sending the message to a specific recipient.

But DKIM does define a domain that is responsible for the message.
The RFC even says that explicitly:

   DomainKeys Identified Mail (DKIM) defines a mechanism by which email
   messages can be cryptographically signed, permitting a signing domain
   to claim responsibility for the introduction of a message into the
   mail stream.

DKIM usually signs the To: and Cc: headers as well, so except in the case
of a Bcc: recipient, it does even show that the domain is responsible
for sending to particular recipients.

Of course, since DKIM public keys are typically distributed via DNS, the
security of DKIM is only as good as the security of DNS (ie, it's not secure.)

But in that far-off candy-mountain time when everyone uses DNSSEC and
no CAs are compromised by hackers or governments, then DKIM will in fact
securely declare that a given domain is responsible for a given message.
And even without secure DNS, DKIM is pretty useful in practice.

Regards,

David.

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Mon, 12 Sep 2011 22:56:23 +0200

Hi, David,

On 9/12/11 9:31 PM, David F. Skoll wrote:
> Douglas Otis<[email-masked]>  wrote:
>

Doug means (as far as I can tell) something like:

Technologies like GPG/PGP and S/MIME use the private key of the sender 
in combination with the public key of the recipient and the private key 
of the recipient in combination with the public key of the sender, to 
achieve encryption/message integrity/non-repudiation for this specific 
pair of sender+recipient.

DKIM signs header From and optionally header To:, Cc: etc, but the 
recipient of the message is determined by envelope To, not by header To 
or Resent-To or any other header. So bad guys, using too-big-to-block 
domains, can create a signed spam message by sending from this domain to 
one of their other mailboxes and replay that message, using the original 
DKIM signature.

Doug may speak for himself if I've misunderstood him.

However, I strongly agree with Dave that DKIM and SPF are just examples 
in the context of the charter and are out of scope for the reputation WG.

/rolf

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 12 Sep 2011 17:01:52 -0400

On Mon, 12 Sep 2011 22:56:23 +0200
"Rolf E. Sonneveld" <[email-masked]> wrote:

> So bad guys, using too-big-to-block domains, can create a signed
> spam message by sending from this domain to one of their other
> mailboxes and replay that message, using the original DKIM
> signature.

Got it.  But that's OK; the "too-big-to-block" domains will gravitate
towards a neutral or mildly negative reputation, as they should, while
domains for which DKIM is really useful (ebay.com, paypal.com,
yourbank.com) are unaffected by this attack assuming they don't let
bad guys inject arbitrary messages through their signing servers.

In other words: A domain that allows "bad guys" to inject arbitrary
messages through their DKIM-signing servers really *deserves* a worse
reputation than one that doesn't.

Regards,

David.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Sep 2011 14:56:48 -0700

> for sending to particular recipients.
David,

DKIM is not intended to convey accountability for a sending domain nor 
intended recipients.  Indeed a message might not include intended 
recipients, which this list's messages do not.  Nor should one assume 
DKIM is related to the domain sending the message.  DKIM's overly broad 
statement should not be read as conferring accountability for any 
specific outbound MTA for any specific recipient.  Only signed message 
content (which may ignore pre-pended From header fields) is covered by a 
DKIM signature.  This coverage excludes essential aspects of the message 
envelope needed to properly assess accountability.

 From a reputation standpoint, DKIM is unable to hold spammers 
accountable.  It fails to authenticate who sent any specific message.   
Spam is not defined based upon who generated content.  The act of 
spamming is by those domains sending unwanted content to specific 
recipients.  Neither the sending domain nor the recipient can be assumed 
covered by a valid DKIM signature.  It would be dangerous to base domain 
reputations on an assumption these properties are generally true.

Neither DKIM nor SPF provide a suitable basis for establishing 
reputation.  Nor should their shortcoming be excused because high volume 
domains will be white-listed to protect them from possible false 
assumptions.  Since the desire of this list is to not discuss validation 
issues, an assumption of specific "validation/authentication" methods 
should be excluded from the Repute charter.

Even as a service that signals which domains are "too big to block", 
since any DKIM message can be replayed from any outbound MTA to any 
recipient, such a service would be prone to abuse.

-Doug

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 12 Sep 2011 18:24:59 -0400

On Mon, 12 Sep 2011 14:56:48 -0700
Douglas Otis <[email-masked]> wrote:

> reputation.

I disagree WRT DKIM.  DKIM doesn't assert that a particular domain
sent a particular message, true.  It *does* assert that that domain's
signing server has seen the message and signed it.

So it's perfectly feasible to talk about the reputation of a DKIM
signing domain, which is not necessarily the reputation of the message
sender, but is still useful.  I posted the use-cases earlier.

Regards,

David.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Sep 2011 15:28:49 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of David F. Skoll
> Sent: Monday, September 12, 2011 3:25 PM
> To: [email-masked]
> Subject: Re: [domainrep] Charter going to the IESG
> 

Indeed, I've constructed an experimental reputation system based on this idea: Domains that "stamp" a message with a DKIM signature are taking some responsibility for it, and thus it's possible to develop a reputation as to whether or not that domain's stamp tends to be associated with spam or not.  The system doesn't care who sent it or who received it, only who stamped it.

I'm planning to strap the protocols defined in the repute drafts onto the front end as an example implementation.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Sep 2011 17:26:49 -0700

Murray,

An interesting experiment, but not one that should be endorsed within 
the Repute charter.

You are free to have an overly optimistic belief the lack of replay 
control permitted by ignoring sender and recipient won't be abused.  
Adding this "optimism" to the charter is still not wise nor necessary 
for such experimentation.

-Doug

---

From: "David F. Skoll" <[email-masked]>
Date: Mon, 12 Sep 2011 20:41:32 -0400

On Mon, 12 Sep 2011 17:26:49 -0700

> control permitted by ignoring sender and recipient won't be abused.  

Yes, but the whole point of the reputation system is that signing servers
that permit abuse will be revealed to have a poor or neutral reputations
whereas signing server that do not permit abuse will have a good reputation.

We see this even now.  DKIM-signing by gmail.com is not worth much,
but DKIM-signing by my bank is.

Regards,

David.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 12 Sep 2011 18:51:45 -0700

> but DKIM-signing by my bank is.
Why wouldn't use of DANE in conjunction with outbound servers offer a 
safer mechanism which would offer domains true control over what is 
being sent?  This would also help solve the IPv6 dilemma.  Why endorse a 
mechanism that excludes protection for the majority of email sources 
that could otherwise benefit from a reputation service not easily 
poisoned?  Would such victims of poisoning abuse have any remedy?

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 12 Sep 2011 20:03:34 -0700

On 9/12/2011 6:51 PM, Douglas Otis wrote:
> Why wouldn't use of DANE in conjunction with outbound servers offer a safer
> mechanism which would offer domains true control over what is being sent?
...

Doug,

You seem to have mis-posted your note.  Clearly it is intended for the dane 
working group.

For the domainrep mailing list, discussion of dane is clearly out of scope.

Really, Doug, most people do not find it that difficult to keep their postings 
within scope for a mailing list.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 12 Sep 2011 21:11:25 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, September 12, 2011 5:27 PM
> To: [email-masked]

Indeed, just as you are free to be overly (and singularly) pessimistic about the potential of the concept.

Nothing about what I said is in the charter though, except that the charter doesn't preclude the idea.

As Dave said, we are all aware that you have pet peeves with SPF and DKIM, but there is clear consensus that the flaws you highlight ad nauseam are at best corner cases that should not deter continued advancement of this work or work on those protocols.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 13 Sep 2011 12:08:27 -0700

On 9/12/11 9:11 PM, Murray S. Kucherawy wrote:
> > -----Original Message----- From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Douglas Otis Sent:
> > Monday, September 12, 2011 5:27 PM To: [email-masked] Subject:
> > Re: [domainrep] Charter going to the IESG
> >
> > You are free to have an overly optimistic belief the lack of
> > replay control permitted by ignoring sender and recipient won't be
> > abused. Adding this "optimism" to the charter is still not wise nor
> > necessary for such experimentation.
>
>  Indeed, just as you are free to be overly (and singularly)
>  pessimistic about the potential of the concept.
>
>  As Dave said, we are all aware that you have pet peeves with SPF and
>  DKIM, but there is clear consensus that the flaws you highlight ad
>  nauseam are at best corner cases that should not deter continued
>  advancement of this work or work on those protocols.

Murray,

Sorry for the trouble.  This is only to challenge erroneous statements 
made in the charter as it relates to Security.
,--
"Various mechanisms have been developed for associating a verified 
identifier with email content, such as with SPF (RFC4408) and DKIM 
(RFC4871). ... Given the recent adoption of domain name verification for 
email, by SPF and DKIM, the most obvious initial use case for reputation 
is for email."
'--

There are several Security problems with these two statements related to 
reputation that the Repute mailing list is unwilling to discuss.  There 
is no reason to make them in the charter, where simple removal would be 
a remedy.  Alternatively, this might suggest an experiment using DANE 
with outbound MTAs and there would also not be any Security concern 
wasting our time.

The Security aspects relate to a domain's inability to defend their 
reputation when based upon either IP address authorization or signed 
messages that exclude sending domains and intended recipients.  This has 
real DoS potential.

There is no way to know whether statistical exceptions are legitimate.  
The "at best corner cases" represents every message sent from this 
mailing list or any message sent using BCC, for example.  The same 
issues occur with shared outbound MTAs where every email potentially 
falls into easily exploitable "corner cases".  Defending this requires 
that recipients refuse all exceptions.

Email reputation is challenged to respond to the introduction of IPv6.  
Already the announced prefix space (ignoring the lower 64 bits) is more 
than 56,000 times the entire IPv4 address range and growing 
exponentially.  Perhaps the prefix space alone will soon start 
flattening out at about 340,000 times that of the entire IPv4 address space.

Deployment of IPv6 over IPv4 is problematic.  The current strategy is to 
use Dual-Stack Lite.
http://tools.ietf.org/html/rfc6333
http://tools.ietf.org/html/draft-bpw-pcp-nat-pmp-interworking-00
This moves CPE NAT to the ISP or enterprise tunnel over 192.0.0.0/29.

This change in Internet infrastructure demands deprecation of IPv4 
address based verifications, and replacement with secure end-to-end 
methods.  Neither is meet by SPF or DKIM.  There is little time to waste 
so we need to be smart and use the right tools.

-Doug

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 13 Sep 2011 12:20:10 -0700

> Sent: Tuesday, September 13, 2011 12:08 PM
> To: [email-masked]
> [...]

In light of Pete's recent post:

I submit that the participants here have read and considered your concerns, but there is no rough consensus supporting the idea that the charter needs the change you are suggesting.  Rather, consensus appears to agree that creating a general reputation infrastructure with DKIM and SPF as example applications within it is the right way to proceed.

-MSK

---

From: Pete Resnick <[email-masked]>
Date: Tue, 13 Sep 2011 14:28:51 -0500

I agree. And Doug, you are of course free (and encouraged) to make 
comments to the IESG when the charter goes out for IETF-wide review. I 
assure you that your comments will be taken under consideration.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102