On Aug 30, 2013, at 7:50 PM, Andrew Sullivan
<ajs(_at_)anvilwalrusden(_dot_)com> 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