headers
Arvel Hathcock | 1 May 2008 01:49
Favicon

Re: forward movement, please? (was RE: Are lookalike domains like parent domains?)

So, I take this as a "no" to the compromise proposal (at least from one 
person).  That's too bad.

> Having the ADSP specification include normative text that calls for 
> validating the From field domain name does two things:
> 
> 1. Couples an entirely separate and more generally useful mechanism 
> (checking domain name validity) to one that is considerably more limited 
> (ADSP).

I believe that a normative reference would require that the result of an 
already widespread practice be part of an ADSP evaluation.  Where the 
practice is not already extant, claimed compliance with ADSP could 
require it.  That's all.

> 2. Modifies SMTP.  (Yes, really.)

I don't understand, please explain.  This sounds new.

> Having non-normative text that describes it serves to promote the idea 
> but not couple it with the fate of ADSP.

Non-normative language leaves ADSP deployers in the dark about whether 
the protocol can be relied on because success would depend upon an 
optional NXDOMAIN check that some have, some don't, and none need 
perform.  Since we know the protocol needs this in order to avoid being 
trivially defeated and since it has already been acknowledged as a 
common practice it seems inexcusable for an engineering team to make it 
an optional thing or to simply "promote the idea."
(Continue reading)

Permalink | Reply | 2 comments |
headers
Wietse Venema | 1 May 2008 01:54

Re: forward movement, please? (was RE: Are lookalike domains like parent domains?)

Dave Crocker:
> 
> 
> Arvel Hathcock wrote:
> > I propose that the side advocating removal of the NXDOMAIN check agree 
> > to language which makes this step AT LEAST a SHOULD and preferably a MUST.
> 
> 
> Having the ADSP specification include normative text that calls for validating 
> the From field domain name does two things:
> 
> 1. Couples an entirely separate and more generally useful mechanism (checking 
> domain name validity) to one that is considerably more limited (ADSP).
> 
> 2. Modifies SMTP.  (Yes, really.)
> 
> Having non-normative text that describes it serves to promote the idea but not 
> couple it with the fate of ADSP.

Instead of discussing how many angels fit on a pinhead, I suggest
that we do something sensible, like: ADSP is bound to DNS, and
therefore it's defined only for author domains that exist in DNS.

	Wietse
Permalink | Reply | 2 comments |
headers
Dave Crocker | 1 May 2008 02:02

Re: 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
(Continue reading)

Permalink | Reply | 12 comments |
headers
Al Iverson | 1 May 2008 02:05
Favicon

Re: forward movement, please? (was RE: Are lookalike domains like parent domains?)

On Wed, Apr 30, 2008 at 3:25 PM, J D Falk <jdfalk <at> returnpath.net> wrote:
> Arvel explained:
>
>  > The debate has shifted from outright hostility to any NXDOMAIN check
>  > at all (complete elimination of it in it's
>  > entirely) to just removing it from a required algorithmic step and
>  > instead referencing it non-normatively with some version of "this is a
>  > good idea that you might want to think about if you're not already
>  > doing it."
>  >
>  > This is where we are at present on the NXDOMAIN issue I believe but
>  > others might have a different view.
>
>  That's my impression, as well.
>
>  What's the path towards settling this?

Vote? Survey?

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.
Permalink | Reply | 0 comments |
headers
Arvel Hathcock | 1 May 2008 02:07
Favicon

Re: 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.
Permalink | Reply | 0 comments |
headers
Al Iverson | 1 May 2008 02:09
Favicon

Re: forward movement, please? (was RE: Are lookalike domains like parent domains?)

On Wed, Apr 30, 2008 at 6:49 PM, Arvel Hathcock <arvel.hathcock <at> altn.com> wrote:

>  > Having non-normative text that describes it serves to promote the idea
>  > but not couple it with the fate of ADSP.
>
>  Non-normative language leaves ADSP deployers in the dark about whether
>  the protocol can be relied on because success would depend upon an
>  optional NXDOMAIN check that some have, some don't, and none need
>  perform.  Since we know the protocol needs this in order to avoid being
>  trivially defeated and since it has already been acknowledged as a
>  common practice it seems inexcusable for an engineering team to make it
>  an optional thing or to simply "promote the idea."
>
>  Perhaps we could get some other people to weigh in on this matter.

I think I agree with you.

I am not understanding what is revolutionary about an NXDOMAIN check.
I see sites rejecting mail based on NXDOMAIN currently, regularly. I
would even dare to call this an observable best practice. I would need
to hear more on how it modifies SMTP and/or turns the universe on its
ear -- I'm not yet convinced that it is as earth shattering as
described.

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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Al Iverson | 1 May 2008 02:14
Favicon

Re: end-users vs filtering engines

On Wed, Apr 30, 2008 at 7:02 PM, Dave Crocker <dhc <at> dcrocker.net> 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.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Arvel Hathcock | 1 May 2008 02:19
Favicon

Re: forward movement, please? (was RE: Are lookalike domains like parent domains?)

> Instead of discussing how many angels fit on a pinhead, I suggest
> that we do something sensible, like: ADSP is bound to DNS, and
> therefore it's defined only for author domains that exist in DNS.

Excellent.

Section 3.2 already lists "the domain does not exist" as a valid ADSP 
result.  So we could add Wietse's text "ADSP is bound to DNS and 
therefore is to be applied only to Author Domains which actually exist 
in DNS." as the first sentence of section 3 perhaps?

Arvel
Permalink | Reply | 0 comments |
headers
Douglas Otis | 1 May 2008 03:47

Re: forward movement, please? (was RE: Are lookalike domains like parent domains?)


On Apr 30, 2008, at 5:09 PM, Al Iverson wrote:

> I am not understanding what is revolutionary about an NXDOMAIN  
> check. I see sites rejecting mail based on NXDOMAIN currently,  
> regularly. I would even dare to call this an observable best  
> practice. I would need to hear more on how it modifies SMTP and/or  
> turns the universe on its ear -- I'm not yet convinced that it is as  
> earth shattering as described.

NXDOMAIN represents the DNS RCODE 3 "Name Error" response.  This code  
is meaningful when retuned by an authoritative DNS server and  
represents a specific heuristic of DNS.  For example, this code might  
occur when a referral at an existing domain name contains a CNAME that  
does not exist.

Keep in mind, it is possible to resolve hostnames locally without  
dependence upon DNS.  Resolving such SMTP clients locally might  
represent _crucial_ services expected to function even when DNS is  
unavailable.  After all, DNS represents a potential target for DDoS  
attack.  The specific use of NXDOMAIN as an ADSP compliance/acceptance  
test may interfere with alternative methods of resolving hostnames,  
whether or not DKIM or ADSP is used by the SMTP client's domain. : (

NXDOMAIN protection also fails when wildcards are used.  In addition,  
NXDOMAIN requires ADSP records be placed at _every_ existing node,  
rather than just those potentially supporting SMTP.  Clearly, knowing  
whether a domain might support SMTP offers far greater value than  
knowing a node exists but may contain no resources, or none related to  
SMTP.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Arvel Hathcock | 1 May 2008 04:12
Favicon

Re: Why only exact domains matter

>> 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?"
> 
> Where you say "exact domain" I presume you mean "subdomain", but I'd
> flip it around to make it clearer.

I'm saying that an attackers use of "i-look-like-domain.com" does not 
diminish or defeat the level of protection which ADSP provides to 
"domain.com".  In fact, ADSP will push _all_ attackers to move to 
"i-look-like-domain.com."  I view this as a good thing, others don't and 
I'm struggling to understand why.

Arvel
Permalink | Reply | 1 comment |

Gmane