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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Aug 30, 2013, at 7:50 PM, Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> 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 

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.


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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]