Re: [ietf-dkim] end-users vs filtering engines
-Original Message- From: [EMAIL PROTECTED] [mailto:ietf-dkim- [EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Thursday, May 01, 2008 6:03 PM To: J D Falk Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] end-users vs filtering engines J D Falk wrote: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. This relies on a resource that is not specified in the document, is not publicly standardized, and changes. Not such a good thing. d/ -- But is it such a bad thing Dave? This is why I'm suggesting specifying how the domain owner can articulate the policy but not specifying (at this point) how a receiver might use it. It's that old King Canute thing that John likes to bring up. Different receivers will take different approaches for taking advantage of A=Y initially. Why would this be an issue? I have a strong feeling that the domain owners most likely to take advantage of something like this do not have tons of subdomains in their trees. I expect ADSP records to generally have (relatively) long TTLs. Do we expect most adopters to be changing their policies willy nilly? If I really wanted to make a change I would shorten up the TTL and then wait until well after the original TTL had passed to make the change. It's only an issue if someone has already published an ADSP policy - wouldn't it be nice if we could get ADSP out the door so people could actually start implementing? The overall hit in terms of lookups, tree walking, etc is not likely to be significant. I would expect (early) implementers to cache the results locally for the duration of the TTL rather than going externally for an ADSP lookup for each and every piece of email. There is a reason the name was changed from SSP to ADSP. With respect to that we should be asking ourselves how to empower author domains to express their signing policies in ways that then empower receivers to make rational decisions about how to handle (validly) signed vs unsigned email. J.D. and several others have indicated that they would determine base domains manually with regard to various TLD practices. I go back to my original question to receivers. Would an A=Y (or however syntactically constructed) assertion be sufficiently useful to receivers and reputation service providers that they would take advantage of it? Would it make sense to require an ADSP publisher wishing to utilize this to publish it for all (that would be a MUST) subdomains in a tree making such an assertion? If receivers and reputation service providers don't feel such an assertion is particularly useful then we can drop the discussion and move on to other things. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Wietse Venema wrote: Jim Fenton: Dave Crocker wrote: J D Falk wrote: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. This relies on a resource that is not specified in the document, is not publicly standardized, and changes. Not such a good thing. Exactly what terrible outcome does this produce if this is done wrong? It's unlikely that com, ac.uk, or org.au are going to publish ADSP records. So there is an unnecessary query to the parent, which is probably cached anyway (15 minutes for com, 1 day for ac.uk). Jim, You deleted the context of the original question: a mechanism that allows organizations to advertise a policy in one place that applies to their entire DNS tree. I didn't delete anything but Dave's signature line and the mailing list footer. Please check the thread. I'm very sensitive to being taken out of context, and try not to do the same. What is in the ssp-03 draft is not a mechanism to advertise a policy in one place that applies to their entire DNS tree. It is a mechanism to advertise a policy that applies to leaf nodes (only) one level down, such as A records within the domain. In the absence of a solid algorithm that determines the top of an arbitrary organization's DNS tree, verifiers will have to walk up the entire DNS tree from the bottom. Or those publishing ADSP records will need to do so for each of their subdomains (as distinct from hostnames). Of course, hostnames are much more numerous than subdomains, so this reduces the publication requirement significantly. Thus, ADSP becomes a tool thay can be mis-used for trivial amplification attacks by sending rfc2822.from addresses with many domain levels. That is not a good thing for a protocol that attempts to improve security. The prime directive should be do no harm. Several revisions back, SSP had provision for a record search that was either unbounded or 5 layers deep, which was abandoned for this (among other) reasons. The current draft, and the proposal on the table, is to perform a maximum of one additional lookup if an ADSP record is not found and the domain exists. I don't see that as introducing a significant amplification or make-work attack. This is one of the reasons I react so strongly to the term tree walk for this. It's a single additional query, maximum. -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
I sensed my name invoked and was compelled to join the melee. -Original Message- From: [EMAIL PROTECTED] [mailto:ietf-dkim- [EMAIL PROTECTED] On Behalf Of Al Iverson Sent: Wednesday, April 30, 2008 8:15 PM To: DKIM List Subject: Re: [ietf-dkim] end-users vs filtering engines On Wed, Apr 30, 2008 at 7:02 PM, Dave Crocker [EMAIL PROTECTED] wrote: While perhaps it closes off some particular names, it does not close off the class of attack at all. It is one thing to have a mechanisms that makes it incrementally more difficult for an attacker to succeed. It is quite another to make it no harder at all. If all the attacker has to do is register a new name and use a string-replacement on their previous attack, we do not have any meaningful added protections. Dave, this actually reads as though you suggest we throw out ADSP all together. I don't see how this limit doesn't apply to ADSP regardless of tree walking functionality. So the question is what sort of mechanism is going to benefit from locking sub-domains, but not cousin domains? How is the benefit meaningful? I don't understand the question but I suspect it's a variant of what's already been asked and answered. Is there something new here? Asked, yes. Answered, I don't think so. Well, I certainly proposed one potential scenario where sub domain locking would be useful (to me, arguably not to you). Archives suggest Michael Hammer would prefer sub domain locking, as have Jim Fenton's comments. Perhaps they could theorize an example or two of where and how this would be useful to them. Cousin domains are orthogonal to the ADSP issue. Focusing on subdomains, I believe it may be useful for both senders and checking receivers if a domain were to be able to assert whether it's policy applies to all of it's subdomains. Given that we don't know how receivers or reputation services might utilize such an assertion, I would avoid must or should for a check at this stage. My reasons for stating this is as follows: 1) In my estimation, ADSP is particularly useful for both senders and receivers if it asserts that all mail is signed and/or discardable. There is certainly some value if limited to only a specific domain/subdomain but potentially greater value if an assertion can be made that covers part or all of a tree. This allows a domain owner to make a broader statement about it's practices. 2) The ability to make a policy assertion across the board from a base domain may empower receivers and reputation services in their efforts to identify good - as in conforms to signing policy - vs bad as in does not match the domain owners stated policies through the mechanisms they are empowered to express them through. ADSP is (or should be) a public mechanism to extend and replace the private one-on-one agreements/relationships that a handful of senders and receivers have engaged in to fight (forged) spam and phishing prior to having a public standard based option. 3) If such a policy assertion is included in ADSP then I have abiding faith and confidence that there are those legitimate receivers and reputation services that will take advantage of such an assertion. I wouldn't even mandate any sort of tree walking, MX checks, NXDOMAIN checks, etc on the receiver side with regard to such a policy assertion. The assertion could be something as simple as a=y where a is all subdomains sign and y is yes. I want to emphasize that I am not currently at the point where the domains I work with could make such a policy assertion but I am close (maybe one exception per domain tree) and would strive to get there if I were empowered through ADSP to make such an assertion. What I would like to hear from software providers, receivers and reputation folks is whether they would see a benefit from or take advantage of such assertions by (particularly) large heavily phished domains and other domains in general? Ultimately, I'll implement whatever I can get from this ADSP process whether narrowly scoped or more broadly scoped. As I see it we are incrementally closing off specific spaces from specific types of abuse. Nothing more and nothing less. For our website (brand) domains) we have intentionally restricted the subdomains that we send email from. The ability to assert signing for all subdomains in a tree makes it clear to receivers that any subdomain in that tree should have a valid signatureeven subdomains that exist but are not necessarily used for email currently. If need be we will publish an ADSP record for every domain we use. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
MH Michael Hammer (5304): Focusing on subdomains, I believe it may be useful for both senders and checking receivers if a domain were to be able to assert whether it's policy applies to all of it's subdomains. Given that we don't know how receivers or reputation services might utilize such an assertion, I would avoid must or should for a check at this stage. How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. -- J.D. Falk Receiver Products Return Path work with me! http://www.returnpath.net/careers/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
On May 1, 2008, at 2:06 PM, Wietse Venema wrote: MH Michael Hammer (5304): Focusing on subdomains, I believe it may be useful for both senders and checking receivers if a domain were to be able to assert whether it's policy applies to all of it's subdomains. Given that we don't know how receivers or reputation services might utilize such an assertion, I would avoid must or should for a check at this stage. How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way they do for example.uk.com or example.dyndns.org. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Dave Crocker wrote: J D Falk wrote: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. This relies on a resource that is not specified in the document, is not publicly standardized, and changes. Not such a good thing. Exactly what terrible outcome does this produce if this is done wrong? It's unlikely that com, ac.uk, or org.au are going to publish ADSP records. So there is an unnecessary query to the parent, which is probably cached anyway (15 minutes for com, 1 day for ac.uk). -Jim ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
J D Falk: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. And who will provide updates to all the ADSP verifiers in the field? Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Jim Fenton: Dave Crocker wrote: J D Falk wrote: Wietse wrote: How would a receiver discover the top-level domain given example.com, example.ac.uk, example.org.au, etc.? The same way we do now: annoying, manually maintained case statements. This relies on a resource that is not specified in the document, is not publicly standardized, and changes. Not such a good thing. Exactly what terrible outcome does this produce if this is done wrong? It's unlikely that com, ac.uk, or org.au are going to publish ADSP records. So there is an unnecessary query to the parent, which is probably cached anyway (15 minutes for com, 1 day for ac.uk). Jim, You deleted the context of the original question: a mechanism that allows organizations to advertise a policy in one place that applies to their entire DNS tree. In the absence of a solid algorithm that determines the top of an arbitrary organization's DNS tree, verifiers will have to walk up the entire DNS tree from the bottom. Thus, ADSP becomes a tool thay can be mis-used for trivial amplification attacks by sending rfc2822.from addresses with many domain levels. That is not a good thing for a protocol that attempts to improve security. The prime directive should be do no harm. Wietse ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] end-users vs filtering engines
Folks, Arvel Hathcock wrote: Assume, say, one million people who regularly receive valid emails from their bank ([EMAIL PROTECTED]). If they received an email from [EMAIL PROTECTED], how many of them would believe the email is really from the bank? I assure you, lots. Through liberal use of sub-domains via email and web sites end users have been trained to ignore the sub-domain part ... MTA operators will be using/deploying ADSP. End-users are the intended beneficiary (as is the case with _all_ filtering systems). The motivation driving MTA operators to deploy ADSP is end-user protection. There is a difference between intending end-user benefit, versus intending end-user processing. We need to be quite clear about what entity is actually going to process the information ADSP is supplying. From your note, it isn't clear where you expect the processing to be done. If the goal is end-user processing of differential information about domain names in the From: field, then I urge us to shut the effort down now. Seriously. There is no empirical basis for believing that the protection of these ADSP features will be a) understandable by end-users, or b) hard for attackers to bypass. Absent strong and clear empirical basis, we have to rely on general precepts about humans factors, and these, I am afraid, do not support this effort. If it's for end users, my experience says that they are equally likely to be fooled by [EMAIL PROTECTED], which would suggest we've been wasting our time. I agree with the first part of what you've said but the second part does not follow logically. One can not claim that because we fail to protect a user completely we therefore aren't able to provide any protection at all and have thus wasted our time. ADSP isn't attempting to solve the accounts-bigbank.com problem. But it does solve the foo.bigbank.com problem. This is wonderful news and a welcome step forward. Let's consider this some more: Users will not distinguish between [EMAIL PROTECTED] and [EMAIL PROTECTED] No matter how much you protect the use of one, you cannot protect against use of the other. So, cousin domains provide an utterly trivial path for bypassing the intended end-user protection. Standards are costly to develop, deploy and use. A global standard had better provide strategic benefit. That means persistentAs explained, this won't do that. Even if one believes that it protects the name space it seeks to protect, the ability to bypass that protection trivially means that there is no real end-user benefit. As a consequence, what you claim as protection really is not meaningful protection. Some of us in this working group have some background in human factors, usability, user-centered design, and the other topics (and buzzwords) of the human side of computer use. Most of us do not. As a working group, we have amply demonstrated a complete lack of skill in designing for end-user processing. So we need to stop trying. Filtering engines, on the other hand, are far more tractable as targets. As a group, we know a fair amount about them. They can be taught to map a particular domain name to a particular reputation and then apply that diligently. However as has been noted, filtering engines are more typically using precise strings, rather than name root strings. In any event, this basic confusion about intended use of ADSP is one of the several reasons there is no real consensus about it or its features. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
There is a difference between intending end-user benefit, versus intending end-user processing. I suppose so. I'm talking about intending end-user benefit. The only reason any mail administrator turns on a filter is to provide benefit to end-users. If the goal is end-user processing of differential information about domain names in the From: field, then I urge us to shut the effort down now. This is not the goal. Users will not distinguish between [EMAIL PROTECTED] and [EMAIL PROTECTED] Right, but filtering agents will and they are now being offered a mechanism to eliminate an entire category of exploitation emails. No matter how much you protect the use of one, you cannot protect against use of the other. So, cousin domains provide an utterly trivial path for bypassing the intended end-user protection. So, are you saying that because we don't provide protection against cousin domains we should drop our effort to provide protection against mis-use of exact domains? Standards are costly to develop, deploy and use. A global standard had better provide strategic benefit. That means persistentAs explained, this won't do that. Even if one believes that it protects the name space it seeks to protect, the ability to bypass that protection trivially means that there is no real end-user benefit. I don't think so. Forcing phishers to use accounts-bigbank.com when today they are free to use bigbank.com directly is a significant step forward both for receivers and senders. Receivers benefit because no matter how similar accounts-bigbank.com appears to a human no filtering agent will be confused into equating it with bigbank.com and that has important implications for accurate filtering. Senders benefit by regaining some measure of control over the use of their own domain which for many is an important corporate brand and business asset. As a consequence, what you claim as protection really is not meaningful protection. It seems meaningful enough to me. Some of us in this working group have some background in human factors, usability, user-centered design, and the other topics (and buzzwords) of the human side of computer use. Most of us do not. As a working group, we have amply demonstrated a complete lack of skill in designing for end-user processing. So we need to stop trying. We're not trying. All I've pointed out is that the purpose for using filters is to benefit end-users. Are you disputing the truth of that claim? Filtering engines, on the other hand, are far more tractable as targets. As a group, we know a fair amount about them. They can be taught to map a particular domain name to a particular reputation and then apply that diligently. However as has been noted, filtering engines are more typically using precise strings, rather than name root strings. In any event, this basic confusion about intended use of ADSP is one of the several reasons there is no real consensus about it or its features. I don't think anyone's confused about where ADSP fits. It's a piece of the mail filtering process. Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
On 4/30/08, Arvel Hathcock [EMAIL PROTECTED] wrote: I don't think so. Forcing phishers to use accounts-bigbank.com when today they are free to use bigbank.com directly is a significant step forward both for receivers and senders. Receivers benefit because no matter how similar accounts-bigbank.com appears to a human no filtering agent will be confused into equating it with bigbank.com and that has important implications for accurate filtering. Senders benefit by regaining some measure of control over the use of their own domain which for many is an important corporate brand and business asset. As a consequence, what you claim as protection really is not meaningful protection. It seems meaningful enough to me. I have to strongly with Arvel here. I strongly reject any thought along the lines of we shouldn't pursue methodology X because somebody can bypass it with similar cousin domains. Addressing spoofing by way of cousin domains is necessary, but is a whole separate discussion. It, like protection related to the validation of legitimate domains, are both two small pieces of the authentication and trust puzzle. Suggesting forget it, because they can still get away with a lookalike domain seems to me like saying forget about locking the door; we shouldn't bother, beause it's not the only way a bad guy can enter. Best, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove lists from my email address to reach me faster and directly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Al Iverson wrote: I have to strongly with Arvel here. I strongly reject any thought along the lines of we shouldn't pursue methodology X because somebody can bypass it with similar cousin domains. Addressing spoofing by way of cousin domains is necessary, but is a whole separate discussion. It, like protection related to the validation of legitimate domains, are both two small pieces of the authentication and trust puzzle. Suggesting forget it, because they can still get away with a lookalike domain seems to me like saying forget about locking the door; we shouldn't bother, beause it's not the only way a bad guy can enter. Your last paragraph really gets at the core issue: Is there a sufficiently useful degree of benefit to warrant the (considerable) cost of development, deployment, and use? Is the benefit long-term? In the case of locking the door to one's house, it permanently keeps out casual intruders and it establishes intent to secure the house. So someone breaking down the door is clearly guilty of breaking and entering. These are real, long-term benefits. We have none of that clarity or even benefit, in the current case. A cousin domain is sufficiently trivial to use so as to make the intended protection against use of sub-domains meaningless. If the current mechanism really did raise the bar, that would be one thing, but it doesn't. If a reputation engine has an entry, for a name, it works. Locking subdomains or cousin domains is entirely irrelevant to that. So the question is what sort of mechanism is going to benefit from locking sub-domains, but not cousin domains? How is the benefit meaningful? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Is there a sufficiently useful degree of benefit to warrant the (considerable) cost of development, deployment, and use? What is this question in reference to? The notion of NXDOMAIN lookups or ADSP in general? Is the benefit long-term? Assuming you're talking about ADSP in general, yes. Where-ever and when-ever it is used, DKIM+ADSP can permanently detect the unauthorized use of domain(s) in an email From: header, forever. The benefit is long-term. A cousin domain is sufficiently trivial to use so as to make the intended protection against use of sub-domains meaningless. That is just a restatement of the view which asserts that because ADSP can't protect domains you don't control you therefore needn't bother protecting those you do. So the question is what sort of mechanism is going to benefit from locking sub-domains, but not cousin domains? How is the benefit meaningful? I don't understand the question but I suspect it's a variant of what's already been asked and answered. Is there something new here? -- Arvel ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Arvel Hathcock wrote: Is there a sufficiently useful degree of benefit to warrant the (considerable) cost of development, deployment, and use? What is this question in reference to? The notion of NXDOMAIN lookups or ADSP in general? Arvel, Very sorry for being so cryptic. While I view the questions as applicable for any effort, in this case I meant them with respect to any 'protect the sub-tree' effort. That was why my following comments referred to cousin names. Is the benefit long-term? A cousin domain is sufficiently trivial to use so as to make the intended protection against use of sub-domains meaningless. That is just a restatement of the view which asserts that because ADSP can't protect domains you don't control you therefore needn't bother protecting those you do. My point is that the effective protection is zero. While perhaps it closes off some particular names, it does not close off the class of attack at all. It is one thing to have a mechanisms that makes it incrementally more difficult for an attacker to succeed. It is quite another to make it no harder at all. If all the attacker has to do is register a new name and use a string-replacement on their previous attack, we do not have any meaningful added protections. So the question is what sort of mechanism is going to benefit from locking sub-domains, but not cousin domains? How is the benefit meaningful? I don't understand the question but I suspect it's a variant of what's already been asked and answered. Is there something new here? Asked, yes. Answered, I don't think so. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
Thanks Dave. I hope our discussion can cause some others to come to life and post their thoughts. Arvel Dave Crocker wrote: Arvel Hathcock wrote: Is there a sufficiently useful degree of benefit to warrant the (considerable) cost of development, deployment, and use? What is this question in reference to? The notion of NXDOMAIN lookups or ADSP in general? Arvel, Very sorry for being so cryptic. While I view the questions as applicable for any effort, in this case I meant them with respect to any 'protect the sub-tree' effort. That was why my following comments referred to cousin names. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] end-users vs filtering engines
On Wed, Apr 30, 2008 at 7:02 PM, Dave Crocker [EMAIL PROTECTED] wrote: While perhaps it closes off some particular names, it does not close off the class of attack at all. It is one thing to have a mechanisms that makes it incrementally more difficult for an attacker to succeed. It is quite another to make it no harder at all. If all the attacker has to do is register a new name and use a string-replacement on their previous attack, we do not have any meaningful added protections. Dave, this actually reads as though you suggest we throw out ADSP all together. I don't see how this limit doesn't apply to ADSP regardless of tree walking functionality. So the question is what sort of mechanism is going to benefit from locking sub-domains, but not cousin domains? How is the benefit meaningful? I don't understand the question but I suspect it's a variant of what's already been asked and answered. Is there something new here? Asked, yes. Answered, I don't think so. Well, I certainly proposed one potential scenario where sub domain locking would be useful (to me, arguably not to you). Archives suggest Michael Hammer would prefer sub domain locking, as have Jim Fenton's comments. Perhaps they could theorize an example or two of where and how this would be useful to them. Regards, Al Iverson -- Al Iverson on Spam and Deliverability, see http://www.spamresource.com News, stats, info, and commentary on blacklists: http://www.dnsbl.com My personal website: http://www.aliverson.com -- Chicago, IL, USA Remove lists from my email address to reach me faster and directly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
