On Tue, Sep 3, 2013 at 12:34 PM, Douglas Otis <doug.mtview@xxxxxxxxx> 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.
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