ietf
[Top] [All Lists]

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

2013-09-07 02:33:11
On Tue, Sep 3, 2013 at 12:34 PM, Douglas Otis 
<doug(_dot_)mtview(_at_)gmail(_dot_)com> 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
<Prev in Thread] Current Thread [Next in Thread>