Zach,
I feel that you're reading far too much into this. The DMARC
specification specifies a mechanism for interoperability - and that
between systems operated by experts - it absolutely is _*not*_ a recipe
book for beginners.
DMARC is, roughly, attempt #4 at a standardised mechanism[1] for
_*helping*_ willing (and competent) Domain Owners and Receivers to
co-operate on making spoofing _*harder*_ without dependence upon prior
agreements, whether direct or intermediated. No-one (well, no
participant) is representing DMARC as infallible nor, even when it
works, that it makes spoofing impossible. What it does do is materially
improve what can be achieved.
There is a lot to get right for all participants, results will vary with
competence. In the particular examples that you mentioned, of course
receivers should check that they're not determining authentication on
the basis of weak DNS results, test keys, short keys, ridiculously broad
SPF assertions, ... but also, they should be forming and maintaining an
opinion about every Domain Owner whose mail streams they're assessing,
both of their competence (How good a match is there between their
apparent mail-stream and what their authentication information says?
What's the user complaint rate? Do they have a years-long history of
getting all of the SPF/DKIM details right?) and their importance
(presumably a receiver isn't going to show a gold key for a single-user
mail-server which sends a total of a dozen messages a day, no matter how
good their configuration and history is). There are 100 other things
that a receiver has to get right, it appears to me that you're straining
at gnats having already swallowed quite a number of camels.
The mistaken assumptions that you mention ("p=reject is the objective!")
are exactly the same as those made about previous attempts; there is
nothing that can be done to stop people from making this assumption but
it doesn't really matter: competent receivers will form their own
opinion about whether a given Domain Owner's assertions can be trusted
(and incompetent receivers will mess up in 100 other ways anyway).
Your pleas to receivers to not make assertions about authentication are
interesting, but I'd suggest that that ship has long since sailed:
service and technology providers are generally in a far, far better
position to make these assessments than typical users are, even once you
factor in the occasions when they get it wrong. You might equally plead
with browser vendors to drop the visual cues provided for a site that's
correctly using Extended Validation Certificates.
I'd suggest that the appropriate avenue for your concerns is to
co-operate on a best-practices documentation effort and ensure that your
concerns are addressed in that forum. Over time, these documents are
likely to converge.
- Roland
1: The preceding 3 were SPF -all, DomainKeys o=- and ADSP discardable
On 10/29/2012 11:38 PM, Zachary Harris wrote:
On 10/29/2012 10:48 AM, Tim Draegen wrote:
Receivers should consider the strength of the underlying key before
attaching a "Trust Indicator".
Indeed, /when trust indicators are being used/, it would seem
appropriate to insert a SHOULD or MUST on top of RFC6376's basic
statement that "Verifier policies may use the length of the signing
key as one metric for determining whether a signature is acceptable."
But that's not the point I wished to make in the "false positives"
thread. What about DNS cache poisoning (don't forget that SPF and DKIM
are ultimately relying on a UDP link in the chain!), what about replay
attacks, what about compromised systems, what about a whole list of
things in RFC4686 (thanks for pointing me to the reference, Franck;
and thanks Jim for the hard work) which are too numerous for me
personally to have even taken the time to read through all of them?
The point is this: people could be using 8192-bit RSA private keys
("in theory", you know what I mean), and still, I would request
vendors: please don't make statements on my mom's email account that
such and such message *_IS_* from a trusted sender, because you'll
make my reminders to her about "personal responsibility on the
internet" that much more difficult!
-Zach
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
--
Roland Turner | Director, Labs
TrustSphere Pte Ltd | 3 Phillip Street #13-03, Singapore 048693
Mobile: +65 96700022 | Skype: roland.turner
[email protected] | http://www.trustsphere.com/
_______________________________________________
dmarc-discuss mailing list
[email protected]
http://www.dmarc.org/mailman/listinfo/dmarc-discuss
NOTE: Participating in this list means you agree to the DMARC Note Well terms
(http://www.dmarc.org/note_well.html)
