Subject: [ietf-dkim] Are subdomains like parent domains?

From: John Levine <[email-masked]>
Date: 29 Apr 2008 00:25:26 -0000

>> But I have to say, without any sort of domain blanket/coverage
>> option, it seems like something is really missing here.

I'm seeing an implicit assumption that if someone has an opinion about
mail from foo.com, they will have a similar opinion of mail from
subdomains a.foo.com or a.b.foo.com, or a.b.c.foo.com.  I've been
thinking about the mail I actually see, and I am having great
difficulty finding even a small set of real life scenarios where that
is true.

For corporate or ISP domains, they either use one domain for all the
mail, e.g. aol.com, or a handful of regional or divisional subdomains,
e.g. twcny.rr.com or watson.ibm.com.  The other 99% of the names under
the main domain are random hosts whose names are unlikely to appear as
mail addresses* in real mail.  Even companies that outsource some of
their mail to ESPs tend to use a small number of subdomains, e.g.,
Orbitz' weekly newsletters come from my.orbitz.com.  Maybe I'm
suffering from a lack of imagination, but I just can't think of
realistic scenarios where you would want to accept mail from a whole
lot of otherwise unknown subdomains of known domains.

So here's a question for people who run MTAs: when you filter, score,
sort, or otherwise manage your inbound mail stream, do you treat
subdomains the same as parent domains?  Why or why not?

R's,
John

* - as opposed to, e.g., host names in received headers, which neither
DKIM nor ADSP care about.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 29 Apr 2008 10:37:02 +0100

On Tue, 29 Apr 2008 01:25:26 +0100, John Levine <[email-masked]> wrote:

> mail addresses* in real mail.

Not necessarily so. The machine random.example.com, which sits on some  
secretary's desk somewhere, is likely to have an MX record pointing to  
mail.example.com. So all outgoing mail will go through mail.example.com  
(it will be the machine appearing in the EHLO). And the postmaster at  
example.com will ensure that all such necessary MX records are set up.

But the problem is what goes in the From header of mails coming from  
random.example.com? Those will be set by whatever MUA is running on that  
secretary's machine which, if that machine was configured by the Secratary  
herself, will most likely be left by default at random.example.com.

Now a smart postmaster who is an expert in hacking sendmail.cf may well  
arrange to have that From header fixed before it goes out, but don't bank  
on it. And what happens if the secretary wamts to set the From header to  
something completely different, e.g. From: [email-masked] with  
Sender: secretary.example.com? Don't tell me you have never seen that  
particular scenario before :-).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 29 Apr 2008 10:49:24 -0400

> difficulty finding even a small set of real life scenarios where that

Forgive me if we're going in circles, as it's not my intent.

I think I am not looking for an implicit assumption to have the same
opinion about a.b.foo.com. I am thinking of how, as a sender, can I
sign and allow (by actively providing the ability to denote good mail
signed as) foo.com or a.foo.com but prevent the use of (by actively
encouraging filter or reject of) beans.rice.a.foo.com. The latter
being a faked subdomain used by a phisher. So I don't know that it'll
be beans.rice.a.foo.com. It could be plants.animals.a.foo.com today
and tacos.burritos.a.foo.com tomorrow. Out of my control.

Help me understand the best way to handle that, and I think you'll
have me on board.

(Replace foo.com with BigEarthBank.com and you'll get a better
understanding of why I care. These are the people I work with.)

Regards,
Al

--
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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2008 07:58:03 -0700

> difficulty finding even a small set of real life scenarios where that

Good timing.  I had started thinking about the fact that DKIM's d= parameter 
allows differentiating among (sub) domain names.

The premise is that these would have different reputations.  The last thing 
one wants for that is a mechanism that groups them all together.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 29 Apr 2008 15:10:17 -0000

>encouraging filter or reject of) beans.rice.a.foo.com.

Ah, but that begs the question.

What I was asking a few messages back is why anyone who's actually
involved in running e-mail would care whether someone forged
beans.rice.a.foo.com.

I understand why someone in the legal department would want maximum
blanket everything, regardless of cost or feasibility, because that's
what they always want.  But do you know anyone who would treat mail
purporting to be from beans.rice.a.bigbank.com as being from
bigbank.com?  I don't.

R's,
John

---

From: John Levine <[email-masked]>
Date: 29 Apr 2008 15:12:44 -0000

>herself, will most likely be left by default at random.example.com.

Indeed, that used to be a pretty common sloppy setup ten or fifteen
years ago, but few people use sendmail 8.x on our Sun 3's any more.

When's the last time you saw real mail (as opposed to spam using
ancient scraped addresses) with a From address like that?  Maybe I'm
just lucky, but I haven't seen any in a long time.

R's,
John

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 29 Apr 2008 11:14:42 -0400

> involved in running e-mail would care whether someone forged

Yahoo and Hotmail seem to be good candidates to want this. I'm open to
hearing otherwise from them. I think a lack of response on this list
is not equivalent to a negative response, though.

My underlying point is that I need to understand more about how
phishers, once locked out of use of bigbank.com due to DKIM+ADSP, can
best be persuaded to avoid use of account.info.bigbank.com, or any
other subdomain that they've thought of, that I haven't.

Has nothing to do with anyone's legal department. I'd recommend we
pretend that was never raised as a point.

Regards,
Al Iverson

---

From: John Levine <[email-masked]>
Date: Tue, 29 Apr 2008 11:30:48 -0400 (EDT)

> is not equivalent to a negative response, though.

But you're assuming your conclusions again.  I've never heard anyone from 
Yahoo claim that they want automatic ADSP coverage for 
random.junk.yahoo.com, so I see no reason to think that they do.  I've 
never heard anyone from Hotmail express any interest in ADSP at all.

People don't treat mail from [email-masked] as being the same as 
[email-masked].  Yahoo has a small number of well known subdomains they 
use for mail, e.g., groups.yahoo.com, but again, [email-masked] isn't 
the same as [email-masked] either.

Can you show some real life examples where mail from subdomains is treated 
as being mail from the parent domain?  This is a real question -- I can't 
think of any other than some minor elderly special cases but I'm willing 
to believe I'm overlooking something.

Also, keep in mind that if despite the fact that it doesn't matter, you 
really really REALLY want full ADSP coverage on every possible subdomain, 
you can always hire someone to write a specialized DNS server to provide 
it for you, which I think would cover Yahoo and Microsoft.  The question 
is what needs to happen in the general case.

R's,
John

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 29 Apr 2008 11:49:58 -0400

On Tue, Apr 29, 2008 at 11:30 AM, John Levine <[email-masked]> wrote:

> you can always hire someone to write a specialized DNS server to provide it
> for you, which I think would cover Yahoo and Microsoft.  The question is
> what needs to happen in the general case.

I think I'm not the only one making assumptions here.

Let me know if this is going to chill a bit and if there are
opportunities to better understand each other. Or if we're just to the
rock throwing stage, I'll step back, because I'm busy and I don't see
the need.

Al

---

From: Dave Crocker <[email-masked]>
Date: Tue, 29 Apr 2008 08:57:27 -0700

> other subdomain that they've thought of, that I haven't.

Al, I think you have phrased a very useful question.  But I also think it 
highlights a problem in how we've been pursuing things.

In all likelihood, we can assume that phishers will, in fact, try to use 
sub-domains.  I believe the real question is not the one you put forward but 
rather:

      How will it benefit phishers to use arbitrary sub-domains?

How, exactly?

   1. What is the scenario on the receive side that will make this beneficial?

   2. What is the basis for believing that this scenario will, in fact, occur?

So the question is about receive-side, not send-side.

d/
-- 

   Dave Crocker

---

From: John Levine <[email-masked]>
Date: 29 Apr 2008 16:11:45 -0000

>I think I'm not the only one making assumptions here.

Of course not.

I'm honestly trying to figure out whether any mail systems treat mail
from sub.foo.com as being from foo.com when they make decisions about
sorting, filtering, and so forth.  That's why I'd really appreciate
some actual examples if there are any.  I'm not trying to be
confrontational here, I'm trying to gather data.

As far as I can tell, nobody does, but the whole issue of the tree
walk is predicated on this assumption.  If the assumption is indeed
untrue, the treewalk (in any of its varieties) serves no purpose and
we can just get rid of it.

R's,
John

---

From: "J D Falk" <[email-masked]>
Date: Tue, 29 Apr 2008 13:08:57 -0400

>> hearing otherwise from them. I think a lack of response on this list
is
>> not equivalent to a negative response, though.
> 
> But you're assuming your conclusions again.  I've never heard anyone
> from Yahoo claim that they want automatic ADSP coverage for

(As you know, I don't work for either Microsoft/MSN/Hotmail or Yahoo!
anymore, and cannot speak on their behalf.  This is purely my own
opinion, based on externally visible data.)

Both grew organically over the course of 10-12 years, so it's hard to
make sweeping generalizations about their namespaces.

The ADSP statement for yahoo.com (which is Yahoo! Mail) will be
different from groups.yahoo.com (which is Yahoo! Groups, an entirely
different department), which will be different from upcoming.yahoo.com
(which was upcoming.org until about a year ago.)  Even within Mail,
alerts.mail.yahoo.com will be different from addressbook.mail.yahoo.com.

Some branches of the heierarchy could do okay with inheriting the parent
-- but not as far down as yahoo.com.

IMHO the thing about phishers forging nonexistant domains is a
non-issue.  I can not imagine any circumstances where a nonexistant
domain with no possibility of an ADSP statement will be given the same
privleges as an existing domain that does have an ADSP statement.  I can
much more easily imagine someone setting up newservice.example.com
without realizing that their new service falls under example.com's ADSP
statement, thus causing general bad feelings about ADSP and DKIM in
general.

---

From: "J D Falk" <[email-masked]>
Date: Tue, 29 Apr 2008 13:19:18 -0400

> sorting, filtering, and so forth. That's why I'd really appreciate
some
> actual examples if there are any.  I'm not trying to be
confrontational
> here, I'm trying to gather data.

I can think up examples where sub.foo.com would inherit foo.com's BAD
reputation.  That's easy; we've all seen spammers set up a domain and
rotate through subdomains, and we've seen not-quite-entirely-evil
senders do similar things.

I can't come up with very many examples where the subdomain should
inherit the parent's GOOD reputation.  Most banks, hopefully, though
I've seen counter-examples there too: a branch office might have
crappier mailing practices than the main corporate office.

Even the inheritance of badness isn't isn't a safe generalization:
yahoo.com (which has real freemail users) will have a worse reputation
than upcoming.yahoo.com (which I believe consists solely of
announcements sent to registered users.)  Nearly all ISPs will be in the
same situation.

---

From: SM <[email-masked]>
Date: Tue, 29 Apr 2008 10:24:14 -0700

>confrontational here, I'm trying to gather data.

Some senders use email.example.com and example.com.  If you want a 
different treatment for filtering, you'll have to know beforehand 
which subdomains to expect.  It's different if the sender was an ISP 
as host1.adsl.example.net is not treated the same as example.com then.

Regards,
-sm

---

From: [email-masked] (Wietse Venema)
Date: Tue, 29 Apr 2008 13:36:13 -0400 (EDT)

> we can just get rid of it.

We're trying to solve two different problems at the same time.

Question 1: What do real DNS deployments look like? Seems no-one
    can answer that here.  Everyone is concerned that ADSP introduces
    unnecessary barriers for deployment, but discussions about
    random real or fictitious pain symptoms are not the best way
    to define a solution.

    This is an argument to avoid ugly ad-hoc hacks like the two-level
    DNS dance, because they lack a sound foundation.

Question 2: What would the "bad guys" do to side-step DKIM/ADSP,
    for some particular set of ADSP implementation details? I can
    answer that with confidence. They will do everything that gets
    their email through the filters. Unlike ADSP implementors,
    spammers are not bound by the rules of the RFC.  Our lack of
    imagination should not give us a false sense of security.

    This is an argument to have some "safety net" mechanism like
    the ugly two-level dance that automagically covers all nodes
    at the same DNS level; nailing non-existent domains at lower
    DNS levels is already trivial without ADSP.

As fas a I'm concerned someone can toss the coin and be done with
it. I'd rather have something that mostly works now, than something
that will be perfect for one microsecond. No system can be perfect
permanently with respect to constantly changing threats.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Apr 2008 11:17:13 -0700

On Apr 29, 2008, at 8:49 AM, Al Iverson wrote:

>> Also, keep in mind that if despite the fact that it doesn't matter,  
>> you really really REALLY want full ADSP coverage on every possible  
>> subdomain, you can always hire someone to write a specialized DNS  
>> server to provide it for you, which I think would cover Yahoo and  
>> Microsoft.  The question is what needs to happen in the general case.
>
> opportunities to better understand each other. Or if we're just to  
> the rock throwing stage, I'll step back, because I'm busy and I  
> don't see the need.

Phishing attempts may only copy appearance and display names.   
Unfortunately, the email-address used could be anything.  To better  
overcome look-alike attacks, ADSP ALL should enable stricter criteria  
for appearance matches by anti-phish filtering.

Possible counter responses to ADSP:

Of course, any hostname within a phished domain could be mistaken for  
valid non-signing sources, however those lacking MX or A records might  
be excluded on that basis.  Names with underscores such as _adsp, are  
precluded from being valid hostnames by RFC2821, or RFC2821bis as well.

Depending upon bad-actor's reaction to ADSP, domains heavily phished  
_may_ find it beneficial to publish ADSP in conjunction with their  
public hostnames.  Even so, it seems wholly inappropriate to  
facilitate ADSP publishing by imposing a series of DNS transactions  
that will occur with _each_ and _every_ email within _any_ domain.   
These additional transactions may potentially impact otherwise  
uninvolved domains with significant levels of undesired traffic due to  
the distributed nature of email.

-Doug

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 29 Apr 2008 14:17:54 -0400

> statement, thus causing general bad feelings about ADSP and DKIM in

Could I ask you to theorize for me for a moment? Pretend you're a
receiver who sets your own policies, and pretend you're giving it the
kind of thought that a Hotmail or Yahoo would hopefully give to it.

OK, let's assume ADSP has no "tree walking" or "subzone inheritance" feature.
A sender is sending legitimate mails with customercare.bigbank.com
with DKIM and an ADSP policy.
If a phisher sends mail with a PRA of customer-care.bigbank.com, that
would not be signed, and it would not fall under any ADSP policy.

In your perfect world, as an imaginary receiver, how would you discern
between the two sets of messages? What DKIM or ADSP-related measure
could you make that would make it easier for you to can the phishing
mail?

I guess I'm even making an assumption that you would care to do that.
Would you? If not, why not?

If not, what do you theorize the operational objective of ADSP should be?

Al

---

From: Steve Atkins <[email-masked]>
Date: Tue, 29 Apr 2008 11:19:41 -0700

> permanently with respect to constantly changing threats.

There's a third question too. Is ADSP supposed to stand on it's
own, or can it make assumptions about the rest of the filtering
system it's embedded in? If the latter, does it need to be explicit
about it?

Everyone is pretty clear that if mail is "From" a non-existent
domain, it's not likely to be delivered. As such, it's not unreasonable
to not worry about the nasty failure modes in an ADSP algorithm
if they are only triggered by a non-existent domain. But, does the
process of not worrying about it require that it be documented
within the ADSP spec?

None of that will make any difference to real world operational
use, if any, it's just spec wordsmithing.

Cheers,
   Steve

---

From: "J D Falk" <[email-masked]>
Date: Tue, 29 Apr 2008 15:00:33 -0400

Al asked:

> OK, let's assume ADSP has no "tree walking" or "subzone inheritance"
> feature. A sender is sending legitimate mails with
> customercare.bigbank.com with DKIM and an ADSP policy. If a phisher
> sends mail with a PRA of customer-care.bigbank.com, that would not be
> signed, and it would not fall under any ADSP policy.
> 
> between the two sets of messages?

That's easy: any string comparison will tell you that
customercare.bigbank.com != customer-care.bigbank.com.  So, assuming no
treewalking assumption in my reputation system, they'd each have
entirely separate reputations.

But reputation is never based solely on one tiny bit of information --
I'd also check to see if the domain exists.  If it doesn't, that would
very likely result in rejection before even getting to any reputation
algorithm.

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 29 Apr 2008 16:16:04 -0400

JD, thanks. This is very insightful.

> very likely result in rejection before even getting to any reputation

So, a potential way to address this without any sort of "tree walking"
functionality would be:
- As a sender, publish ADSP records for all domains/zones/fqdns you know about
- Recommend that receivers reject mail from non-existing FQDNs used in
PRA or MFROM (or somesuch).

This seems workable. Others who prefer treewalking functionality, why
does this not work for you? Where does this specifically fall down?

Thanks,
Al Iverson

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 29 Apr 2008 13:22:48 -0500

> sorting, filtering, and so forth.  

SpamAssassin does this to a degree.  It itself white-lists and in it's 
documentation encourages others to white-list using *@*.foo.com.  Even 
though other measures might verify that the message isn't a forgery, 
these white-listed entries still treat all sub-domains equally (by 
imputing trust and foregoing filtering entirely).

SpamAssassin's actual tests performed on From: values treat all 
sub-domains equally at least when the tests are performed upon the 
local-part.  This might be expected but it is an example of a mail 
filter system treating *@*.foo.com identically.

Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Tue, 29 Apr 2008 13:08:58 -0500

>       How will it benefit phishers to use arbitrary sub-domains?

If the use of arbitrary sub-domains within an unsigned message can 
"get-around" an otherwise stricter receive-side filter then the benefit 
to phishers is obvious - their pay-load is all the more likely to be 
delivered.  Compliance with the current spec would not permit this to occur.

Arvel

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Apr 2008 14:08:31 -0700

On Apr 29, 2008, at 1:16 PM, Al Iverson wrote:
>
> So, a potential way to address this without any sort of "tree  
> walking" functionality would be:
> - Recommend that receivers reject mail from non-existing FQDNs used  
> in PRA or MFROM (or somesuch).

Disagree.

Recommend ensuring From header SMTP deliverability (based upon the  
presence of SMTP discovery records) and ADSP compliance based upon  
presence or absence of ADSP records.  (Assuming the receiving domain  
only considers addresses valid when SMTP deliverable.)  ADSP is  
referenced by email-address domains contained within the From header.   
The MFROM (return-path) is not included within a DKIM signature.  The  
PRA is not related to assertions made in ADSP.

-Doug

---

From: "J D Falk" <[email-masked]>
Date: Tue, 29 Apr 2008 17:51:23 -0400

> - As a sender, publish ADSP records for all domains/zones/fqdns you

Yep.

> PRA or MFROM (or somesuch).

I'd put that in the category of "things we all know we should be doing,
even though some are slacking on it."

> does this not work for you? Where does this specifically fall down?

Like I said earlier in the conversation, there are a lot of cases where
treewalking would be inappropriate and/or confusing.  I think these
would be the norm, rather than the exception.

--
J.D. Falk
Receiver Products
Return Path 

work with me!
http://www.returnpath.net/careers/

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 30 Apr 2008 11:55:53 +0300

> purporting to be from beans.rice.a.bigbank.com as being from

This seems to be an empirical question, where "I don't" may not
provide much useful information.

Assume, say, one million people who regularly receive valid emails
from their bank ([email-masked]). If they received an email
from [email-masked], how many of them would believe the
email is really from the bank?

I have no idea what the answer would be, but I'm pretty sure it's not
zero or one million. If it's sufficiently large (for some definition
of "sufficient"), I can see that people outside the legal department
would also care.

Best regards,
Pasi

---

From: John Levine <[email-masked]>
Date: Wed, 30 Apr 2008 08:38:25 -0400 (EDT)

> email is really from the bank?

Well, now we have another question -- who's going to be using ADSP, mail 
system operators or end users?  It's always been my impression that the 
main audience is MTA operators, who will use it in filtering decisions.

If it's for end users, my experience says that they are equally likely to 
be fooled by [email-masked], which would suggest we've been 
wasting our time.

R's,
John

PS: You don't have to tell me that this is not a new argument.  But it's 
evidently not one we've resolved.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 10:41:01 -0500

>> 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 
(since it frequently changes) and to focus on the "root domain" part 
(which is constant and they either trust or don't trust).

> main audience is MTA operators, who will use it in filtering decisions.

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.

> be fooled by [email-masked], which would suggest we've been 

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.

Arvel

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 13:41:15 -0400

> problem.  This is wonderful news and a welcome step forward.

I would love to hear a little more from you on scenarios in which the
limited treewalking functionality would benefit you or your receiver
customers. The more specific the better. What potential deliver/not
deliver decisions are made and based on what criteria.

I think I'm looking to understand what you get out of that, versus
what you might get out of "no treewalking functionality, but I reject
non-resolvable FQDNs." It seems like it might be pretty similar. I'm
wondering if that's true.

Al Iverson

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Apr 2008 11:16:29 -0700

Folks,

> web sites end users have been trained to ignore the sub-domain part 
...
> 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.

 > problem.  This is wonderful news and a welcome step forward.

Let's consider this some more:

      Users will not distinguish between [email-masked] and 
[email-masked].

      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

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 13:40:16 -0500

> deliver decisions are made and based on what criteria.

As far as I can understand, the "treewalking" doesn't benefit the 
receivers at all.  It's a convenience items for senders.  From the 
receiver point of view, if a spec says "look here for the ADSP record" 
then receivers will do so and expect that the senders have placed the 
information where it's supposed to be (even if they have to do that 
manually for every one of their sub-domains).  Now, whether and to what 
degree senders will appreciate and embrace this is another matter.

So, from the receiver side, I don't have a problem with the 
"treewalking" - whether it stays or goes.  I don't see it's existence as 
the huge problem that others do but if it disappeared tomorrow this 
would not destroy the essence of ADSP (it would just increase it's 
deployment complexity).

It's been pointed out to me that I've confused this "treewalking" 
discussion by forgetting that this thread is not discussing the NXDOMAIN 
issue.  I have done this and I'm sorry about that.  I view the NXDOMAIN 
check as essential since it is impossible for domain administrators to 
deploy ADSP records for sub-domains that do not exist.

Arvel

---

From: Steve Atkins <[email-masked]>
Date: Wed, 30 Apr 2008 11:51:06 -0700

> would not destroy the essence of ADSP (it would just increase it's

It would increase deployment complexity for senders.

It would decrease deployment complexity for receivers.

Given that senders seem to be those who want to get this deployed,
and so are motivated to do so even if doing so is complex, while
receivers are more ambivalent then removing this feature seems
a reasonable idea.

> deploy ADSP records for sub-domains that do not exist.

If the goals of ADSP are what I'm guessing they are, +1.

Cheers,
   Steve

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 14:14:57 -0500

> 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.

> [email-masked].

Right, but filtering agents will and they are now being offered a 
mechanism to eliminate an entire category of exploitation emails.

> 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.

> 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

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 15:27:50 -0400

> If the goals of ADSP are what I'm guessing they are, +1.

Could you all help me to understand this point in more detail. Define
the NXDOMAIN issue for me, and how it relates to receiver filtering
decisions. Examples welcome. (I have some idea of what I think this
means, but I'd like to see it clarified to better understand it.)

Best regards,
Al Iverson
Somewhere on I-65 in Indiana

---

From: Steve Atkins <[email-masked]>
Date: Wed, 30 Apr 2008 12:49:20 -0700

> means, but I'd like to see it clarified to better understand it.)

The NXDOMAIN thing means only one thing for a receiver. Don't
accept mail that claims to be from non-existent domains.

The reason there's discussion about it is that one of the ways
in which ADSP is iffy is that it only doesn't allow you to state
"I don't send unsigned mail from any hostname that ends
in .example.com". If your domain is example.com, and I
decide to send mail claiming to be from
mail.flooble.example.com there's no way you can publish
an ADSP record to assert that that mail isn't from you, unless
you guess the magic word "flooble".

You, of course, don't care because you know there's no
hostname or MX record for mail.flooble.example.com, so
no right-thinking recipient will consider it legitimate mail
anyway.

The discussion is not over what recipient behavior in that
case will actually be (reject or discard it because it's
claiming to come from someone who doesn't exist), rather
it's over whether the ADSP spec needs to prescribe that
behavior.

Cheers,
   Steve

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 16:00:54 -0400

>  no right-thinking recipient will consider it legitimate mail

Thanks, that's what I thought, I think.

What if the from is a subdomain that isn't being used for mail, but
commonly exists. Let's say I set up DKIM+ADSP for spamresource.com and
mail.spamresource.com. Without any sort of tree walking, if I forget
to configure ADSP for www.spamresource.com, this could potentially get
through as "doesn't have DKIM but the domain is legit." Isn't this a
potential loophole that is resolved only by a very careful vetting of
everything in your domain tree and ensuring each hostname/zone is
configured with ADSP? Or am I wrong on that?

It seems like the treewalking would help to address stuff like this....?

Best,
Al

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 15:02:21 -0500

> means, but I'd like to see it clarified to better understand it.)

Eric Allman described the problem well in this thread:

http://mipassoc.org/pipermail/ietf-dkim/2008q2/009936.html

But, I'll have a crack at it myself.

Suppose example.com wants to protect itself from unauthorized use 
through an ADSP policy of "I sign all mail."  Suppose further that it 
deploys this policy to every one of it's sub-domains.  At this point 
example.com has done everything it can to tell the world "I sign all 
mail."  Given the above, attackers can no longer send mail as 
example.com or any existing sub-domain thereof to an ADSP capable 
receiver without detection (and consequent filtering action).  This is 
very good.

Now suppose that the attacker decides to send the mail from 
doesnt-exist.example.com.  Note that this sub-domain is still part of 
example.com yet since "doesnt-exist" doesn't exist there is no way the 
administrator at example.com could have deployed an ADSP record for it 
and where there is no ADSP record, the algorithm requires a result of "I 
do not sign everything."  Thus is ADSP defeated and we become, in my 
view, a laughing stock for overlooking an obvious hole in our algorithm.

Enter the NXDOMAIN check.  If, as part of the ADSP algorithm, an 
NXDOMAIN check is performed, the algorithm can quickly detect that the 
domain doesn't exist and that _this_ might be the reason there is no 
ADSP record.  This added insight closes the hole and can be used by 
filtering agents.

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.

Arvel

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 16:08:00 -0400

> 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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 30 Apr 2008 13:12:01 -0700

> configured with ADSP? Or am I wrong on that?

Exactly right.

> It seems like the treewalking would help to address stuff like  

Not in general. It will help only in the case where there are only one
level of hostnames below the top level domain. It won't help in
the cases where that's deeper.

People whose work environments consist solely of three level
hostnames see it as a magic bullet. Those who don't, see it as
a hack that adds complexity for recipients without buying the
senders any functionality they didn't already have via less
intrusive methods.

Cheers,
   Steve

---

From: "J D Falk" <[email-masked]>
Date: Wed, 30 Apr 2008 16:25:24 -0400

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."
> 

That's my impression, as well.

What's the path towards settling this?

--
J.D. Falk
Receiver Products
Return Path 

work with me!

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Apr 2008 13:28:09 -0700

> door; we shouldn't bother, beause it's not the only way a bad guy can

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Apr 2008 14:14:22 -0700

On Apr 30, 2008, at 12:49 PM, Steve Atkins wrote:
> You, of course, don't care because you know there's no hostname or  
> MX record for mail.flooble.example.com, so no right-thinking  
> recipient will consider it legitimate mail anyway.

Agreed.

The positive existence of SMTP related records is safer than reliance  
on the lack of NXDOMAIN returned by some DNS transaction.  NXDOMAIN  
overlooks situations where wildcard records are used for unrelated  
reasons, and where hostnames are obtained by methods outside of DNS.   
Assume next year the XPTR concept becomes popular for securing SIP.   
Due to the ADSP discovery algorithm's reliance on NXDOMAIN (and  
therefore the presence of hostname records in DNS) protection might be  
lost or critical exchanges might be prevented.

The positive existence of a record related to SMTP confirms a domain  
regardless of the use of wildcards or DNS.  ADSP should be declared as  
pertaining to SMTP.  A declaration that ADSP pertains to SMTP appears  
to be the only safe path forward.  While DKIM might be used by other  
protocols, ADSP should be viewed as protecting SMTP exchanges to  
establish a logical and safe framework.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 17:01:40 -0500

> What's the path towards settling this?

I propose that the side advocating maintaining the NXDOMAIN check as an 
actual algorithmic step agree to remove this from the algorithm 
description in favor of placement somewhere else.

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.

This is a completely reasonable and sensible way to close the issue IMO.

We are down to the bare-bones of what many of us are able to accept with 
regard to further fundamental changes.  Unbelievable compromise has 
already been made and no side is getting all of what they want.  We're 
now talking about trimming ADSP to the point of near uselessness. 
There's no more flesh we can carve from this pig and still make a sandwich.

Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Apr 2008 15:12:34 -0700

> 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.

d/
-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Apr 2008 15:37:25 -0700

On Apr 30, 2008, at 3:01 PM, Arvel Hathcock wrote:

>>> This is where we are at present on the NXDOMAIN issue I believe  
>>> but others might have a different view.
>>
> I propose that the side advocating maintaining the NXDOMAIN check as  
> an actual algorithmic step agree to remove this from the algorithm  

NXDOMAIN would remain a problem regardless where in the specification  
it is placed. : (

> 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.

How about:

Recipients SHOULD check for the existence of SMTP discovery records,  
to confirm absence of ADSP.

ADSP MUST provide recipient value from their checks.

> We are down to the bare-bones of what many of us are able to accept  
> with regard to further fundamental changes.

ADSP should declare protection for messages publicly exchanged over  
SMTP, instead of all public exchange protocols that might employ DKIM  
at some point in the future.  The specification has failed to trim  
itself in a few important areas.   ADSP should be limited to positive  
existence checks, and specific public exchange transports.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 17:59:29 -0500

> (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.

> 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.

> 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

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 18:49:19 -0500

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."

Perhaps we could get some other people to weigh in on this matter.

Arvel

---

From: [email-masked] (Wietse Venema)
Date: Wed, 30 Apr 2008 19:54:54 -0400 (EDT)

> 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

---

From: Dave Crocker <[email-masked]>
Date: Wed, 30 Apr 2008 17:02:18 -0700

Arvel Hathcock wrote:
> 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.

> can't protect domains you don't control you therefore needn't bother 

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?
> 

Asked, yes.  Answered, I don't think so.

d/

-- 

   Dave Crocker

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 19:05:09 -0500

>  What's the path towards settling this?

Vote? Survey?

Regards,
Al Iverson

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 19:07:00 -0500

Thanks Dave.

I hope our discussion can cause some others to come to life and post 
their thoughts.

Arvel

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 19:09:54 -0500

>  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

---

From: "Al Iverson" <[email-masked]>
Date: Wed, 30 Apr 2008 19:14:59 -0500

>  string-replacement on their previous attack, we do not have any meaningful

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.

>  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

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 19:19:34 -0500

> 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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Apr 2008 18:47:21 -0700

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.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Apr 2008 21:12:22 -0500

>> "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

---

From: John Levine <[email-masked]>
Date: 1 May 2008 01:18:57 -0000

Any filtering engine that will be effective against phishing needs to
deal with lookalike domains no matter what ADSP does.  I asked a few
days ago for reports of filters that consider subdomains equivalent to
the parent domains, and got pretty sparse responses* that tell me that
if there are any that do, it's certainly not widespread, nor is it
common for legit mailers to use huge numbers of subdomains in their
mail.  (If they use sub-huge numbers of subdomains, they can publish
ADSP for each, no harder than publishing A and MX.)

So whatever I'm going to do about lookalike domains, I'm also going to
do about lookalike domains that happen to be subdomains.  Moreover,
even if ADSP were to do the one-level tree walk, I'm still going to
need my lookalike domain stuff for second and deeper level subdomains
since ADSP doesn't help there.

This tells me that the tree walk doesn't make my task as a receiver
any easier, while complicating the lookup.  It's just cruft, and
probably cruft that causes needless pain along the lines of that
caused when SPF fans accuse normal forwarders of "forgery" because SPF
(as we all know) fails to deal with relayed mail.  So forget it.

R's,
John

* - One guy still uses an old workstation mail system that puts the
host name into the return address like they did 15 years ago, and
there may be something in spamassassin that does so, sort of.

---

From: <[email-masked]>
Date: Wed, 30 Apr 2008 22:50:13 -0400

tree walking is much like a MIB walk in SNMP, useful for discovery ddos when everyone and their  brother do it continuously. I really dont see the benefit.
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of John Levine
Sent: Wed 4/30/2008 9:18 PM
To: [email-masked]
Subject: [ietf-dkim]  Why only exact domains matter

R's,
John

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 1 May 2008 11:01:35 +0200

Arvel Hathcock wrote:

> 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.

Trying a summary, _adsp._domainkey.bank.example. can implicitly
also protect foobar.bank.example.  At first glance that is a nice
to have feature.  Looking closer the opposition can simply abuse
foobar-bank.example. (replacing a dot) or foo.bar.bank.example.
(adding a dot) to get around _adsp._domainkey.bank.example.  So
ASP might do less than you hope, but that is not the main point:

IFF foobar.bank.example. is a separate zone below bank.example.
you'd get a limited sitefinder-verisign.museum. effect for ADSP,
and that is a very seriously "bad thing", foobar.bank.example.
would be forced to "opt out" of this invasion of its zone, or
bank.example. would need to close out foobar with t=s.  OTOH we
are at the point where discussing this for another year likely
won't add new insights. 

 Frank