Re: [ietf-dkim] ADSP, was Lists BCP draft available
(More from a review of the lists BCP chatter, with an eye toward a forthcoming document update...) -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Wednesday, May 26, 2010 2:23 PM To: Scott Kitterman Cc: DKIM List Subject: Re: [ietf-dkim] ADSP, was Lists BCP draft available Such transient trust can't be spoofable. It needs to have properties such that if it asserts trust me, it was signed by PayPal when I got it, so you can ignore their discardable flag it can't be used by arbitrary senders to bypass PayPal's ADSP. I don't know of a way to do that which doesn't require a trust relationship with the mail list provider. If you have such a relationship then it's relatively trivial to just not bother with ADSP checks for mail from such lists. I'm left not knowing what advantage there would be from a more complex standardized approach. Right, and where I have problems is that I doubt that most admins have any clue whatsoever which lists their users subscribe to. Some certainly have policies which may inform them (= don't do it), but beyond that this sounds somewhere close to an impossible task. I don't think it's too far-fetched to think that one or more of the following will eventually be true: 1) A signing domain, in this case a list provider, will develop a reputation that it does proper DKIM validation before re-signing, and thus that its A-R header fields can be trusted by receivers; 2) A signing domain will appear in a VBR-like service, with the voucher attesting to the fact that the signer does DKIM properly, and thus that it's a-R header fields can be trusted by receivers; 3) The need to have this kind of transient trust will be a sufficiently rare case that manual exception list maintenance scales just fine. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
--On 7 June 2010 17:37:14 +0200 J.D. Falk jdfalk-li...@cybernothing.org wrote: On Jun 7, 2010, at 11:52 AM, Brett McDowell wrote: But I've seen several posts to this list suggesting life is better if such messages simply never reach the subscribers' inbox. To be honest, I don't recall the motivation for that position. There've been a couple of studies where users were discovered to be going into their spam folder, and falling for bank phishing messages there. At Sussex, we made the decision a few years back that we either deliver mail to the INBOX, or reject it at SMTP time. A spam folder, for many users, is equivalent to a blackhole. Rejecting at SMTP time, in theory, allows the sender of a false positive to choose another contact method. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On Jun 3, 2010, at 12:20 PM, Amir Herzberg wrote: On Wed, Jun 2, 2010 at 8:57 PM, Brett McDowell brett.mcdow...@me.com wrote: ... A = sender of message from an ADSP=discardable domain but the message was not DKIM signed B = sender of message from an ADSP=discardable domain and the message was DKIM signed C = the MLM who is a participating MLM in the authenticated email ecosystem D = receiver of email from the MLM who is a participating receiver (DKIM/ADSP inbound) Note: this scenario takes place after this IETF DKIM WG standardizes the new header I mentioned above. In this scenario C will report to D that the message from A was not signed on inbound and that the message from B was. Shouldn't C discard such message instead of sending it to D? Good question. I don't have a strong opinion either way (yet). The fact that MLM's deliver those messages today enables what we've seen on this list, i.e. at least the message is in subscribers' spam folders which enables them to configure their MUA's to deliver such things in the future. But I've seen several posts to this list suggesting life is better if such messages simply never reach the subscribers' inbox. To be honest, I don't recall the motivation for that position. IIRC, the original motivation was to avoid auto-unsubscriptions from the MLM, but I think we've concluded that MTA's shouldn't bounce those rejected messages back to the MLM anyway. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On Jun 7, 2010, at 11:52 AM, Brett McDowell wrote: But I've seen several posts to this list suggesting life is better if such messages simply never reach the subscribers' inbox. To be honest, I don't recall the motivation for that position. There've been a couple of studies where users were discovered to be going into their spam folder, and falling for bank phishing messages there. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On May 26, 2010, at 12:59 PM, Steve Atkins wrote: On May 26, 2010, at 7:45 AM, Brett McDowell wrote: On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. I agree that adding anything to throw away anything that doesn't have our signature add complexity to implementation and therefore, by definition, is a barrier to adoption. That's not what we are debating. What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem. I *think* the answer is yes. But we haven't yet had the meaningful debate that will resolve that question. Let's debate whether transient trust through a MLM is actionable. Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing? I say yes and yes. But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model. Thoughts? Aesthetically I like the idea of some way for the MLM to tunnel authentication information through to the recipient. Perhaps that's common ground we just discovered. Let's build on that. But I don't think it's clear that doing so would change anything at the recipients MX. As a concrete example, if two subscribers to a mailing list send mail to the list, one DKIM signed and one not, and the list then signs each message and sends it to the recipient, is there any reason that the recipients MX would treat those two messages differently? Yes. But we need more information about the scenario in order to describe how. The following detail will illustrate how. A = sender of message from an ADSP=discardable domain but the message was not DKIM signed B = sender of message from an ADSP=discardable domain and the message was DKIM signed C = the MLM who is a participating MLM in the authenticated email ecosystem D = receiver of email from the MLM who is a participating receiver (DKIM/ADSP inbound) Note: this scenario takes place in after this IETF DKIM WG standardizes the new header I mentioned above. In this scenario C will report to D that the message from A was not signed on inbound and that the message from B was. This would lead D to deliver the message from B but not deliver the message from A. The MLM signed both messages before sending to D. -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. I agree that adding anything to throw away anything that doesn't have our signature add complexity to implementation and therefore, by definition, is a barrier to adoption. That's not what we are debating. What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem. I *think* the answer is yes. But we haven't yet had the meaningful debate that will resolve that question. Let's debate whether transient trust through a MLM is actionable. Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing? I say yes and yes. But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model. Thoughts? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On May 26, 2010, at 7:45 AM, Brett McDowell wrote: On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. I agree that adding anything to throw away anything that doesn't have our signature add complexity to implementation and therefore, by definition, is a barrier to adoption. That's not what we are debating. What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem. I *think* the answer is yes. But we haven't yet had the meaningful debate that will resolve that question. Let's debate whether transient trust through a MLM is actionable. Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing? I say yes and yes. But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model. Thoughts? Aesthetically I like the idea of some way for the MLM to tunnel authentication information through to the recipient. But I don't think it's clear that doing so would change anything at the recipients MX. As a concrete example, if two subscribers to a mailing list send mail to the list, one DKIM signed and one not, and the list then signs each message and sends it to the recipient, is there any reason that the recipients MX would treat those two messages differently? Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
Brett McDowell brett.mcdow...@me.com wrote: On May 25, 2010, at 8:43 PM, Scott Kitterman wrote: Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. I agree that adding anything to throw away anything that doesn't have our signature add complexity to implementation and therefore, by definition, is a barrier to adoption. That's not what we are debating. What we are debating is whether such complexity is a necessary evil that we should provide a specification to support -- as an optional mechanism for stakeholders who want to opt-in to the authenticated email ecosystem. I *think* the answer is yes. But we haven't yet had the meaningful debate that will resolve that question. Let's debate whether transient trust through a MLM is actionable. Would a new header that enabled the MLM to report to the receiver that they indeed validated the original signature actually make any difference in the deliverability of that message to the receiver, and if yes, is that actually a good thing? I say yes and yes. But I expect that if we debate this specific point one of you might highlight an unintended consequence that would tip the balance away from pursuing such a model. Thoughts? That's not quite the question. Such transient trust can't be spoofable. It needs to have properties such that if it asserts trust me, it was signed by PayPal when I got it, so you can ignore their discardable flag it can't be used by arbitrary senders to bypass PayPal's ADSP. I don't know of a way to do that which doesn't require a trust relationship with the mail list provider. If you have such a relationship then it's relatively trivial to just not bother with ADSP checks for mail from such lists. I'm left not knowing what advantage there would be from a more complex standardized approach. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On 5/26/10 2:23 PM, Michael Thomas wrote: I don't know of a way to do that which doesn't require a trust relationship with the mail list provider. If you have such a relationship then it's relatively trivial to just not bother with ADSP checks for mail from such lists. I'm left not knowing what advantage there would be from a more complex standardized approach. Right, and where I have problems is that I doubt that most admins have any clue whatsoever which lists their users subscribe to. Some certainly have policies which may inform them (= don't do it), but beyond that this sounds somewhere close to an impossible task. Domains that assert ADSP all or discardable are assisting recipients who might be inundated with messages spoofing their From domain. This assistance can be extended by also indicating which employed third-party service may benefit from Author Domain signature exceptions. Every increase in the number of sources granted a policy exception represents an increased opportunity for exploitation. For example, specific authorizations of communications via mailing lists run by standard's organizations, or NGOs, would offer recipients far better security, than would resorting to unlimited numbers of different email domains having undefined authentication polices. While much can be said for reputation services, they are not good at preventing abuse from otherwise reputable sources. An authorization scheme for ADSP greatly reduces a domain's exposure within an environment seeing a growing diversity of abuse. Importantly, a DKIM specific authorization scheme places the burden of retaining trust on the sender, where it belongs. If you agree with this, stop kvetching. :^) No one requires senders to defend their recipients. Allowing ADSP to be more comprehensive with a simple and deterministic authorization mechanism, enables greater use and provide a stronger rationale for employing these policies. -Doug The significant problems we face cannot be solved at the same level of thinking we were at when we created them. Make everything as simple as possible, but not simpler. -- *Albert Einstein* ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
Step three: fix the status quo for *participating* MLM's by offering up a new technical solution that enables MLM's to assert that they've validated the original sender's signature. Not to pick on Paypal specifically, since this is a general failure of ADSP, but: We want everyone to throw away mail from us that doesn't have our signature. no, wait, ... We want everyone to throw away mail from us that doesn't have our signature EXCEPT if it has an A-R header showing that it was signed when a MLM received it. no, wait, ... We want everyone to throw away mail from us that doesn't have our signature EXCEPT if it has an A-R header showing that it was signed when a MLM received it AND it has a signature from the MLM to show it's actually from the MLM no, wait, ... We want everyone to throw away mail from us that doesn't have our signature EXCEPT if it has an A-R header showing that it was signed when a MLM received it AND it has a signature from the MLM to show it's actually from the MLM AND the signature is known to the recipient to sign mail from real MLMs. no, wait, etc. I entirely endorse Paypal's efforts to make it easy to identify their mail and easy to throw away the forgeries. But you (and anyone else whose transaction mail is a forgery target) shoot yourself in the foot every time you make the message more complex, since that makes it less likely that people will go along. In particular, all of the normal mail from paypal.com says one thing, log in and look at your account, so losing the occasional message isn't a big deal since you can find what it said on the web site. Now you're saying, well, actually, there's some paypal.com mail that says other stuff that you can't reconstruct, and that mail may well show up without our signature. Really, really, don't do that. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On May 25, 2010, at 1:46 PM, John R. Levine wrote: Step three: fix the status quo for *participating* MLM's by offering up a new technical solution that enables MLM's to assert that they've validated the original sender's signature. Not to pick on Paypal specifically, since this is a general failure of ADSP, but: snip Colorful, but those were not my/our words or sentiment. Once again, our use case is: On Apr 26, 2010, at 1:19 PM, McDowell, Brett wrote: From my perspective, I'd like to enable (not mandate or expect universal compliance with) the deployment scenario where the sender's DKIM signature is either maintained without adulteration or proxied by the list so the transient trust can be carried through the mailing list intermediary to the destination (per Murray's note which I'm also going to respond to). That's my use case. By sharing this use case I'm not trying to deprecate or undermine John Levine's original use case. But there is a diversity of valid/appropriate behavior by mailing lists vis-a-vis DKIM that we need to consider (which is why I'm so pleased to see Mike H. take our discussion in this direction). -- Brett There are mailbox providers who want to leverage email authentication technologies to protect their users from phishing. I'm not making that up. What we have done with Google and Yahoo! is well known, but who here actually believes those are the only two deployments in the world today (or in-process)? I don't think it's in the best interest of the Internet to leave these use cases with no alternative but to pursue closed, proprietary mechanisms. It is my opinion that the standards community (if not IETF, then who?) could view these use cases as an opportunity to evolve the standards in a way that will gain more adoption and utility. The only thing we would be doing is evolving the existing standards to enable -- not compel or coerce -- consumer protection use cases. Everything I've articulated since joining the mail list has been rooted in the concept of choice. This authenticated messaging ecosystem is optional, not mandatory. Any effort to make it mandatory is doomed. So why not provide the option? Why not spec out a means for MLM's to participate in a DKIM/ADSP=discardable flow in a way that supports consumer protection use cases? -- Brett ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
Colorful, but those were not my/our words or sentiment. Once again, our use case is: Maybe, I'm dim, but I don't see any practical difference between what you're saying and what I'm saying, other than perhaps that you have a far more optimistic idea of what people will deploy that doesn't directly benefit them. Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
On 5/25/10 4:18 PM, John R. Levine wrote: Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. Don't deliver rather than throw it away retains email integrity with feedback necessary for ceasing abusive sources. For example, what prevents ISPs from publishing bogus PTR records in their reverse DNS entries? Removing uncertainty of non-compliance better ensures how reports of abuse will be handled. Uncertainty is caused by not allowing domains a means to unilaterally make exceptions on their behalf. The information such an exception mechanism provides better conform to current email infrastructure, and will be safer to act upon. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ADSP, was Lists BCP draft available
John R. Levine jo...@iecc.com wrote: Colorful, but those were not my/our words or sentiment. Once again, our use case is: Maybe, I'm dim, but I don't see any practical difference between what you're saying and what I'm saying, other than perhaps that you have a far more optimistic idea of what people will deploy that doesn't directly benefit them. Like I said, throw away anything that doesn't have our signature has some chance of broad adoption. Every extra word you add to the message makes it less likely that people will do it. I agree with this. I have yet to see any proposals for additions that didn't either add enough complexity to act as a barrier to deployment or alternately make it trivially possible to allow third parties to create messages that render discardable moot. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
