As someone who spent part of his previous career working on email, OS and browser trust UI's, I submit at the end of the day each company or application will make their determination of the right term. These terms (and others) have debated comparing trusted sender, known sender vs safe sender (and others). This is less of a technical discussion, but one of user experience and legal.
Considering the attacks targeting mail providers and ESPs, once their systems are compromised (and the spammer or cybercriminal have the keys to the kingdom), I suggest DMARC (as well as SPF and DKIM) could lead to a false sense of security. We should expect these threats moving upstream to continue. From: [email protected] [mailto:[email protected]] On Behalf Of Franck Martin Sent: Monday, October 29, 2012 9:48 AM To: Zachary Harris; [email protected] Subject: Re: [dmarc-discuss] trust indicators based on weak keys (Was Re: False positives with "p=reject") I found also this document interesting, it talks about key encryption equivalence. http://www.nsa.gov/business/programs/elliptic_curve.shtml In short to protect a 128bits symmetric key, you need a 3072bit asymmetric key. This does not apply much to DKIM, as DKIM does not use another key. But https uses an asymmetric key to transmit a random session bound symmetric key. The rest of the session then uses this much faster symmetric key. However it shows that other type of asymmetric keys would be more DNS friendly (i.e. shorter to store in a TXT record). For info: this group does not deal with "trust indicators" like it does not deal with mailing lists. We limited the scope of the group, to be able to progress one step at a time. These issues will have to be tackled, sure, but after the base is done. From: Zachary Harris <[email protected]> Date: Monday, October 29, 2012 8:38 AM To: "[email protected]" <[email protected]> Subject: Re: [dmarc-discuss] trust indicators based on weak keys (Was Re: False positives with "p=reject") 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)
