Subject: Re: [apps-discuss] AppsDir review of draft-ietf-repute-model-08

From: Douglas Otis <[email-masked]>
Date: Fri, 30 Aug 2013 16:24:17 -0700

Dear Tony,

Use of DKIM offers a very poor authentication example, since this draft makes the same errors made in RFC5863.  It is wrong to suggest the DKIM protocol permits associating a validated identifier to a message as stated in the Introduction.  This is the same erroneous conflation of a message fragment with that of a message.  In most cases, DKIM does not adequately protect message integrity as explained in http://tools.ietf.org/html/draft-otis-dkim-harmful-03.  In addition, DKIM can not authenticate who is accountable for having sent the message which makes it impossible to safely assign reputation.  As such, DKIM should never be referred to as a message authentication protocol.  StartTLS would represent a much better example. 

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Tue, 3 Sep 2013 12:34:57 -0700

On Aug 30, 2013, at 7:50 PM, Andrew Sullivan <[email-masked]> wrote:

> Colleagues, and Doug especially,
> 
> The message I sent (below) wasn't intended as a "shut up and go away"
> message, but a genuine query.  I have grave doubts that TLS is the
> right example (to begin with, I think fitting it into the REPUTE
> approach, given the existing CA structure, would also be
> controversial); but I'm genuinely trying to understand how to make the
> document better, & not trying to tell anyone to go away.
> 
> Best,
> 
> A
> 
> On Fri, Aug 30, 2013 at 07:39:24PM -0400, Andrew Sullivan wrote:
>> Hi Doug!
>> 
>> On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote:
>> 
>>> Use of DKIM offers a very poor authentication example
>> 
>> Thanks for the feedback.  I don't recall you having made this point on
>> the repute mailing list.  Did you, & I missed it?

Dear Andrew,

Sorry for the delay.  I have been overwhelmed by pressing personal matters.

When the REPUTE list first started, I commented about DKIM's inability to support fair reputation, and about 1 year ago, and then again a few months ago IIRC.  These comments were ignored with some denouncement appearing in other venues by various DKIM advocates.  This is understandable since motivation for REPUTE was aimed at establishing DKIM domain reputations to supplant a lack of adoption of a DKIM reputation service.  Lack of adoption was not because DNS was unable to return a resource record referenced at a domain managed by a reputation service.  Even during DKIM's inception, issues related to DKIM's replay feature (to be compatible with SMTP) and its impact on ensuring fair reputation was discussed.  DKIM's validity is not related to intended recipients nor the entity issuing the message.  It seems some expect the "authenticated" signed DKIM message fragment can act as a proxy for a message's provenance.  Unfortunately, DKIM provides inadequate protection of the message's integrity as seen by recipients. 

I'll repeat the information contained in 
http://tools.ietf.org/html/draft-otis-dkim-harmful-03

DKIM and email in general lack a status indicating whether a message structure is valid as defined by RFC5322, RFC6152, RFC6532, and RFC6854.  Logically, a valid message structure with respect to singleton header fields should have been a DKIM requirement for valid signatures.  Without valid message structure, what a recipient sees can be trivially exploited and abused whenever extending a signed DKIM message fragment as a proxy for the message's source.  The hacks recommended in RFC5863 section 8.15 were offered as a method to better ensure message structure, but these are seldom implemented or noted.

Both the repute model and RFC5863 erroneously conflate verification of a DKIM message fragment with that of the entire message.  Such conflation is valid in reference to actual message sources as determined by the IP address (ignoring BGP spoofing) or via StartTLS with certificates obtained from trusted CAs or via DANE.  XMPP use of StartTLS further leverages CAs using OCSP as does most of the protection afforded Today's websites.  XMPP represents a scalable model that could apply to SMTP.

ATPS (RFC6541) also offers a broken example in how a domain is able to authorize an unlimited number of third-party service providers.   ATPS is broken because it must be used in conjunction with a non-standard DKIM signature which defeats its purpose. 

Getting a domain's reputation wrong can prove costly for those hosting reputation services.  Costs include the handling of complaints, notification of abuse, and at times extremely expensive legal defenses.   Some have suggested DKIM reputation can become a type of crowd sourcing as a means to overcome DKIM's limitations, especially since these same advocates also insist DKIM is not being abused. 

A myopic view about reputation and what is meant by "Authentication" will not offer a protocol able to ensure interchange nor will related statistics offer conclusive evidence.   The scale of abuse can be both massive and unfair.

>> Do you have a better example, specifically excluding …

It would be better to not use examples than to offer broken examples.

>> 
>>> StartTLS would represent a much better example.
>> 
>> …this, which strikes me as suffering from a different but related set
>> of issues along the lines you're complaining about?

Can you describe these concerns?  How are these different from most Internet services.  Unlike StartTLS, DKIM is trivially exploited.

I confirmed the ease of this exploit when contacted by Larry Seltzer by using it to achieve both acceptance and inbox placement as a type of phishing demonstration.  What do you think this does to those whose email address or domain is being exploited?  It seems highly unlikely any reputation will ever affect those providers that must be considered Too Big to Block.

http://www.zdnet.com/dkim-useless-or-just-disappointing-spam-yahoo-google-7000019351/

>> Alternatively, if we recast the description of DKIM to call it
>> something else, but still used it as an example of what REPUTE is
>> trying to do, would that solve your objection?

Using DKIM as a basis for reputation is irresponsible. DKIM does not support negative reputation.  Since DKIM messages can be trivially exploited in most cases, this makes any positive reputation assertion highly dangerous.

Repute's  purpose seems aimed at promoting a very bad practice of not really caring about actual accountable entities as evidenced by using DKIM as an example.

Regards,
Douglas Otis

---

From: Hector Santos <[email-masked]>
Date: Fri, 30 Aug 2013 14:37:13 -0400

On 8/30/2013 10:46 AM, Tony Hansen wrote:
>
> The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well.

Hi Tony,

As a high potential implementator of this DKIM-REPUTE framework and 
user of any future REPUTE products based on this DKIM-REPUTE 
framework, I am somewhat disappointed to find not a single integration 
consideration for the highly adopted SPF technology.  Not a single 
mentioning of the word or the integrated use of this highly adopted 
mail transport augmented technology.

Any adopter of this framework or its products who are also SPF 
implementors would need to know at the very least how current 
protocols are affected and also can affect DKIM-REPUTE product 
designers.

For example, DKIM-REPUTE product designers would need to consider SPF 
reputons product models.  Simple text as follows can resolve the 
integration consideration with little SPF fanfare the draft obviously 
tried to avoid:

    REPUTE protocols based on this framework need to consider reputons
    based on SMTP level filtering protocols such SPF [RFC4408],
    IP based filtering [DNSRBL] or others.

    The design consideration for operations may necessitate disabling
    or relaxing SMTP level filters in order to enable filtering based
    on this DKIM-REPUTE model.

I am seeing all this as an integrator of all mentioned mail 
technologies; SPF, SENDERID/SUBMITTER, DKIM, ADSP, VBR.  I welcome 
this REPUTE framework. It should consider the existence of other 
protocols and integrators need some design tips. Besides, for any 
provider of a REPUTE service, they will benefit by these integrated 
considerations as well.

Thanks

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 30 Aug 2013 15:39:14 -0400

Hi Andrew,

I think it can be generalized functional description without 
specifics. Designs based on REPUTE and its users of such products, 
will need some information. That may come (hopefully) from the REPUTE 
product designer. I am suggesting to remind such future REPUTE product 
designers of such considerations.   I think it will help the technical 
marketing of REPUTE products and REPUTE service providers.  If a 
choice has to be made between an SMTP layer filtering protocols and 
some new REPUTE payload filter, then what choices are those to be 
considered.

Keep in mind I would be a classic target audience new reader and user 
of this document. I did not participate in the WG. We should not 
expect the audience of the document to be required to visit archives 
of the Repute WG to find or extract these very real and practical 
integration considerations.  The document should have these general 
considerations summarized.

Thanks

On 8/30/2013 3:20 PM, Andrew Sullivan wrote:
> On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
>>
>> For example, DKIM-REPUTE product designers would need to consider
>> SPF reputons product models.  Simple text as follows can resolve the
>> integration consideration with little SPF fanfare the draft
>> obviously tried to avoid:
>
> Why should the framework document contain details of how various
> particular reputation services interact?  If you want a discussion of
> reputation-service-interaction mechanisms in the draft, that's one
> thing.  If you want to talk about how SPF and DKIM interact, then I
> think this is probably the wrong draft.
>
> Best,
>
> A
>

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Fri, 30 Aug 2013 16:45:36 -0400

On 8/30/2013 4:09 PM, Andrew Sullivan wrote:
> On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:
>
>> archives of the Repute WG to find or extract these very real and
>> practical integration considerations.  The document should have
>> these general considerations summarized.
>
> But your suggestion was for protocol-specific advice.  I don't know
> how to write that in a generic way.  If you have specific text you
> want, I can evaluate.

I had the start of one in my original post:

If too specific (but explain why DKIM is mentioned?), then

    REPUTE protocols based on this framework should consider any
    reputons based on SMTP level filtering protocols in their designs.

with and/or:

Thanks

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Sep 2013 00:04:40 -0700

Hi Tony, thanks for the review.  Apologies for the long delay replying.

On Fri, Aug 30, 2013 at 7:46 AM, Tony Hansen <[email-masked]> wrote:

>  I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).
>
> Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.
>
>
>
> Document:  draft-ietf-repute-model-08
> Title: A Model for Reputation Reporting
>
> Reviewer: Tony Hansen
> Review Date: 2013-08-29
> IESG Telechat Date: 9/12
> IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 superseded that
>
>
> Summary:
> The document is ready for publication. Minor notes follow that can be fixed in AUTH48.
>
> ==== ORGANIZATIONAL COMMENT ====
>
> Section 3 "High-Level Architecture" starts with an extended example of where a reputation service would fit into an existing service. Finally, more than a page later, it starts describing the architecture that is supposed to be the topic of this section. I suggest that the section be split into two, with the beginning given the heading along the lines of "Example of a Reputation Service Being Used", and the "High-Level Architecture" heading moved right before the paragraph that starts "This document outlines". Alternatively, add subsection titles.
>
> Seems reasonable.  I'll do that in the next version.

>
> ==== MINOR NITS ====
>
> Changes below are marked with >>><<<.
>
>
All applied as well.

Thanks again,

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 7 Sep 2013 00:32:25 -0700

On Tue, Sep 3, 2013 at 12:34 PM, Douglas Otis <[email-masked]> wrote:

>
> When the REPUTE list first started, I commented about DKIM's inability to
> support fair reputation, and about 1 year ago, and then again a few months
> ago IIRC.  These comments were ignored with some denouncement appearing in
> other venues by various DKIM advocates.  This is understandable since
> motivation for REPUTE was aimed at establishing DKIM domain reputations to
> supplant a lack of adoption of a DKIM reputation service.  Lack of adoption
> was not because DNS was unable to return a resource record referenced at a
> domain managed by a reputation service.  Even during DKIM's inception,
> issues related to DKIM's replay feature (to be compatible with SMTP) and
> its impact on ensuring fair reputation was discussed.  DKIM's validity is
> not related to intended recipients nor the entity issuing the message.  It
> seems some expect the "authenticated" signed DKIM message fragment can act
> as a proxy for a message's provenance.  Unfortunately, DKIM provides
> inadequate protection of the message's integrity as seen by recipients.
>

[...]

The document under review here provides an architecture for including
reputation evaluation of an identifier, and describes how one would do so
in an existing system such as a mail flow.  Since there are several
existing systems that offer some kind of reputation service predicated on
DKIM and others, DKIM seems a perfectly reasonable example to include.
Some very large operators are on record as stating that they find such
systems useful despite these persistent claims about how insecure DKIM is.

At a very basic level, I don't think REPUTE is the right place to rehash
the discussion about whether DKIM has particular security issues.  I would
refer concerned participants to the DKIM WG mailing list archives for a
record of the protracted debate on that topic, and to the IESG appeals page
for a recent formal revisiting of the issues Doug is identifying here.

Both the repute model and RFC5863 erroneously conflate verification of a
> DKIM message fragment with that of the entire message.  Such conflation is
> valid in reference to actual message sources as determined by the IP
> address (ignoring BGP spoofing) or via StartTLS with certificates obtained
> from trusted CAs or via DANE.  XMPP use of StartTLS further leverages CAs
> using OCSP as does most of the protection afforded Today's websites.  XMPP
> represents a scalable model that could apply to SMTP.
>

If RFC5863 needs correction or update, then that work can be considered,
but it's out of scope for the document under discussion here or the WG that
produced it.  The REPUTE model does not make any statements about the
"entire message" issue being raised here.  Moreover, the Security
Considerations section of the REPUTE email identifiers document does tell
implementers to be aware of the limitations of the protocols on which they
are building services, but again, I don't think REPUTE documents are the
right place to re-tackle those issues.

> Getting a domain's reputation wrong can prove costly for those hosting
> reputation services.  Costs include the handling of complaints,
> notification of abuse, and at times extremely expensive legal defenses.
> Some have suggested DKIM reputation can become a type of crowd sourcing as
> a means to overcome DKIM's limitations, especially since these same
> advocates also insist DKIM is not being abused.
>

The first part of that paragraph is discussed in the REPUTE considerations
document.  Further contributions to that document are welcome since it is
still under WG development.

> It would be better to not use examples than to offer broken examples.

I think that would do this document rather a disservice, since it's
describing how REPUTE works with real-world examples.  I understand that
you don't agree with the safety of the protocols used in the examples, but
I don't agree that removing the examples makes this document a better one.

-MSK