Subject: [ietf-dkim] requirement for one ADSP record per DNS entry makes ADSP undeployable

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 11:13:02 +0200

In order for ADSP to be of use, it must be easily deployable by 
enterprises and service providers.  Otherwise, there is no point in 
bothering to check for answers.  The absence of a parent label check 
will mean that enterprises must list an ADSP record for each and every 
DNS entry they have.  It is not unusual for enterprises to have tens of 
thousands of DNS entries.  The vast majority of enterprises make use of 
provisioning systems that takes years to update and deploy.  ADSP 
deployment is now dependent on those implementations.  Because of that 
ADSP adoption can be expected to lag dramatically behind DKIM.  The 
result will be that recipient sites will infer policy by the existence 
of records and hence implicitly implement a strict test.

Hence as things stand I expect ADSP to never be deployed, and I request 
active consideration of the provisioning systems in use.

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

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 11:16:23 +0200

- sorry - subject line error on my part (that's the only change).

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 13:07:57 +0200

Eliot Lear wrote:
 
> The absence of a parent label check will mean that enterprises
> must list an ADSP record for each and every DNS entry they have.

If they wish to publish "signing practises" they can focus on
domains actually used as "author domain", for a stupid example,
they likely don't need any ADSP for www.example.com.

There is no "requirement for one ADSP record per DNS entry", like
there is no requirement for MX or SPF records per DNS entry.

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 13:37:24 +0200

> there is no requirement for MX or SPF records per DNS entry.

Absent those records, an author domain administrator cannot adequately 
or easily express the simple notion that only certain hosts are 
authorized to send from a domain.  We have thus missed the mark on what 
we are doing.

Eliot

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 14:12:26 +0200

Eliot Lear wrote:

> an author domain administrator cannot adequately or easily express
> the simple notion that only certain hosts are authorized to send
> from a domain.  We have thus missed the mark on what we are doing.

IMO "we" (TINW) are *not* reinventing SPF (or PRA a.k.a. Sender ID).

The admin knows which domains are used for mail, in your example of
a non-trivial organization these domains have MX records.  Just add
_adsp._domainkey.example.com for each example.com with an MX record.

You'd run into problems for wildcard MX records, and for the known 
cases of A(AAA) fallback without explicit MX, so that boils down to
three problematic cases:

1 - wildcard MX
2 - no MX, but an ordinary address (A or AAAA)
3 - no MX, no ordinary address, but a wildcard address

We discussed these problems for months now.  (2) is no ADSP problem,
the admin is supposed to know "implicit MX" cases.  (1) + (3) can't
be addressed without a DNS record directly at the domain, or without
Phil's general solution.  

AFAIK the WG didn't want a new record type, it didn't want to share
SPF records, and it didn't want Phil's proposal, therefore (1) + (3)
won't work for ADSP.  In practise wildcards are rare, aren't they ?

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 14:23:55 +0200

> _adsp._domainkey.example.com for each example.com with an MX record.

The problem is when there are hundreds or thousands of hosts beneath 
example.com.  How many commercial DNS management systems can handle that 
from a provisioning point of view?

Eliot

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 14:56:07 +0200

Eliot Lear wrote:

> example.com.  How many commercial DNS management systems can handle
> that from a provisioning point of view?

After excluding rare wildcard / implicit MX cases what's left might be
hundreds or thousands of hosts with MX records.  Somehow they got the
MX records, and a similar tool can add ADSP records to non-wildcard MX
records.  Is that a problem above the level of "create editor macro" ?

 Frank

---

From: John Levine <[email-masked]>
Date: 27 May 2008 13:47:01 -0000

> The absence of a parent label check will mean that enterprises must
> list an ADSP record for each and every DNS entry they have.

Man, this horse just won't stay dead.

a) Even if you believe this is a serious issue (which I don't, see
point 2 below), the tree walk wouldn't be a solution.  Although I
believe that there is at least one large vendor of network equipment
whose DNS tree is very flat, that's not true in general, and there are
plenty of large systems whose DNS tree is more than two levels deep.
Since those systems would have to cover N-1 levels of their tree even
if we had the tree walk, I don't see any reason to think that the
software changes needed to cover N-1 levels of a DNS tree would be any
easier than to cover N levels.

2) The only reason I can see that one would need to cover every node
in their DNS tree is a belief that other mail admins will assume that
all of your subdomains inherit the reputation of your main domain.
But who'd do that?  Is anyone really going to treat mail from
[email-masked] or even [email-masked] the
same as [email-masked]?  This is to me the reddest of red herrings.
Perhaps somewhere, somehow, there is some admin so stupid as to do
that, but as I hardly need tell you, there's no hope of blocking every
possible stupid mistake that someone else might make.

I also happen to doubt that ADSP will be of much use, but that's
becase I doubt the utility of self-assertions of virtue, not because
DNS management is too hard.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 16:30:31 +0200

John Levine wrote:
> point 2 below), the tree walk wouldn't be a solution.  

First of all, this is a gross mischaracterization of what was in the 
document.  It was NEVER a tree walk, and I have said this before.  I 
would like to understand why you continue to propagate something that is 
blatantly wrong.

> Although I

That doesn't matter.  If there are more levels they are doubtless 
*orders* of magnitude less than the total number of host names.
 
> if we had the tree walk, 

Again a mischaracterization of anything that has been proposed.

> I don't see any reason to think that the

Show how this is relevant to anything.

> same as [email-masked]?  

It's [email-masked] - where 
"your-representative" is actually your representative.  We can and 
should protect from that.

> This is to me the reddest of red herrings.

You are mistaken about who is trying to protect whom from what.  A 
corporation is trying to protect itself from misrepresentation by others 
to others.  And so by not being able to have a PARENT CHECK (which is 
distinctly not tree walking), the corporate admin is forced to have 
faith that someone else isn't stupid.  Worse, if that someone else *is* 
fooled, he or she is going to complain to that admin's management.

If a parent check is not appropriate we need something else that is.  
Perhaps someone who does think ADSP could be useful might provide an 
answer to this question.  One possibility would be to allow for the 
possibility that some of us want a parent check, and to allow for an 
option in the ADSP record to identify that that attempt.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 16:35:05 +0200

Frank Ellermann wrote:
> records.  

That itself is a dependency.  The dependency has two colors: the first 
is that those sites that want to shut down mail from most sites won't be 
able to, and the second is that those who want to specifically authorize 
each host will also have to wait for an update.

> Is that a problem above the level of "create editor macro" ?
>   

It generally has to become part of some sort of host object or class.

Eliot

---

From: "John Levine" <[email-masked]>
Date: 27 May 2008 11:14:05 -0400

Man, this horse still isn't dead.

> document.  It was NEVER a tree walk

It was a one level tree walk, but it's gone now, never to return, so that 
hardly matters.

>> Although I believe that there is at least one large vendor of network 
>> equipment whose DNS tree is very flat, that's not true in general, and 
>> there are plenty of large systems whose DNS tree is more than two 
>> levels deep.

> That doesn't matter.  If there are more levels they are doubtless *orders* of 
> magnitude less than the total number of host names.

Perhaps.  It sounds like you're saying that this is a problem that is very 
important to solve, but not so important as to be worth putting 
incrementally more effort into tool development.  That doesn't strike me 
as a very strong argument.

> "your-representative" is actually your representative.  We can and should 
> protect from that.

You're just reasserting the same implausible claim.  This is part of the 
lookalike problem, and no amount of ADSP will solve that.

ADSP might be of some use against exact name forgery, not lookalike 
forgery.

If the bank has ADSP for mail from [email-masked], bad guys might 
send phishes from [email-masked], but they're at least as 
likely to phish from [email-masked] or [email-masked]. 
Name any large bank, and I will show you hundreds if not thousands of 
registered lookalike domains they don't control, along with quite a lot of 
lookalike domains they do control.  Nobody can tell from the outsde which 
lookalikes are legit, so the only reasonable response to phish forgery is 
to whitelist the small set of real addresses.

Any solution to the lookalike problem that purports to work by putting a 
black mark on all the lookalikes is doomed to failure.  I don't see any 
point in complicating ADSP to at best make it a little easier to put the 
black marks on a modest subset of the lookalikes.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 17:27:10 +0200

John Levine wrote:
> It was a one level tree walk, but it's gone now, never to return, so 
> that hardly matters.
>
>>> Although I believe that there is at least one large vendor of 
>>> network equipment whose DNS tree is very flat, that's not true in 
>>> general, and there are plenty of large systems whose DNS tree is 
>>> more than two levels deep.
>
> Perhaps.  It sounds like you're saying that this is a problem that is 
> very important to solve, but not so important as to be worth putting 
> incrementally more effort into tool development.  That doesn't strike 
> me as a very strong argument.

No it's an argument that dependencies are bad for deployment, and this 
group is creating more.  Good protocol design makes for as few 
dependencies as is necessary to accomplish a task.

> You're just reasserting the same implausible claim.  This is part of 
> the lookalike problem, and no amount of ADSP will solve that.

And you're arguing that ADSP should solve everything, and by removing 
important functionality we will in fact solve nothing.

> ADSP might be of some use against exact name forgery, not lookalike 

Another problem for another day.  Let's not boil the ocean.

Perhaps there is a middle ground here for those who think this case is 
important?  Can we not prohibit something that some believe will be 
important?

Eliot

---

From: John Levine <[email-masked]>
Date: Tue, 27 May 2008 11:33:29 -0400 (EDT)

> And you're arguing that ADSP should solve everything,

It's not helpful to attribute statements to people that they didn't say. 
What I did say is that ADSP may be useful in deterring exact forgery. 
That's all it can do.  No amount of extra cruft will solve the lookalike 
problem.

> and by removing important functionality we will in fact solve nothing.

You keep saying that lookalike protection is "important".  Repeating an 
unpersuasive argument doesn't make it more persuasive.

> important?  Can we not prohibit something that some believe will be 

Nothing's prohibiting you from producing and distributing better DNS 
management tools if you think DNS management is going to prevent ADSP 
usage.  ADSP is mostly for the protection of senders.  If they think it's 
sufficiently important, they'll deploy it.

In any event, the tree walk is gone.  We voted, your side lost.  Enough 
already.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 May 2008 08:36:16 -0700

> from a provisioning point of view?

All.

How else did they register those names and populate them with records?

d/
-- 

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Tue, 27 May 2008 17:37:45 +0200

Eliot Lear wrote:

> "your-representative" is actually your representative.  We can
> and should protect from that.

We can't because it won't work for s/bank.com/co.uk/ and similar
cases, where the parent domain is a different zone.  Read "zone"
where John wrote "tree walk", then it is no mischaracterization.

John tackled this for CSV, I tried to adopt his solution for SPF,
and Wayne tried a normative RFC 2181 chapter 6 reference.  All
failing miserably, the number of levels, one or more, isn't the
issue.  

There was a poll about this recently, and while I don't believe
in voting for technical standards (outside of IESG ballots) I do
believe in "closed issue until new arguments are posted".  

 Frank

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 17:36:33 +0200

John Levine wrote:
> In any event, the tree walk is gone.  We voted, your side lost.  
> Enough already.

We voted on a misconception you perpetuated.  We never had a tree walk.  
The "vote" leaves the protocol undeployable.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 17:48:29 +0200

> How else did they register those names and populate them with records?

They got there with commercial DNS management systems.  Those systems 
are incredibly slow to change.  Go read 
draft-iab-protocol-success-03.txt Section 2.1.1 bullet 2.  While some 
DNS management systems allow for an MX records, their main purpose is to 
handle everyday devices that show up on a network, web servers, and 
other hosts that have nothing to do with mail.  This is most true in the 
enterprise, but also in the service provider.  In the SP environment 
records sometimes aren't even on disk, but generated on the fly. 
In those cases a code change is necessary to generate an appropriate 
ADSP record on the fly.  More code dependency.  John will say, but "who 
cares about adsl-247-6-fixip.some-domain"?  If the point was for senders 
to be able to take responsibility for their domains, they care.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 17:50:08 +0200

> believe in "closed issue until new arguments are posted".  

The result of that poll has opened up a dependency against DNS 
management software, which IMHO is a new issue.

Eliot

---

From: "Al Iverson" <[email-masked]>
Date: Tue, 27 May 2008 10:53:09 -0500

> How else did they register those names and populate them with records?

Implementation of SPF and DK faced similar challenges, and there are
still some registrars that provide DNS services that don't support
batch updates or the right kind of record types. I don't know that it
has been that huge of an adoption barrier overall. And it leaves those
services at a competitive disadvantage, if they don't modify their DNS
administration tools. I've seen registrars update their tools to
support these, and I've seen registrars ignore them. I've guided
clients away from the latter and toward the former. I suspect I'm not
the only one.

I guess my overwhelming point here is that I don't think that the
limitation of certain tools is really a stumbling block. And keep in
mind that we're talking about *certain* tools, because there are
others that would handle this kind of thing just fine.

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 27 May 2008 08:54:45 -0700

> The "vote" leaves the protocol undeployable.

Eliot,

This is both ad hominem and disruptive.

You are seeking review of an issue that has already been voted on, and you are 
doing it in the middle of the group's attempt to focus on a different and 
difficult topic.

In order to permit forward progress, rather than endlessly revisiting resolved 
topics the typical working group normal rule about re-raising a topic that has 
already been closed formally is that something has changed.  New insight, 
changed conditions, or the like.

What has changed, Eliot?

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 May 2008 08:54:45 -0700

On May 27, 2008, at 2:16 AM, Eliot Lear wrote:

>> bothering to check for answers.

Very few senders are going to care about or be able to use ADSP.

Those senders want as many receivers as possible to check ADSP.

So, in order for it to be successful, you need a small number of well
motivated senders to publish records (a one-time effort, along with
a little ongoing, easily automated, maintenance) and you need a
large number of much less motivated receivers to check ADSP on
every single one of hundreds of millions of inbound emails, and their
myriad MTA providers to implement efficient code to do so.

Given that, it's clear that for there to be any chance of successful
deployment is going to be dominated by the receivers. Simplifying
the job for the receiver as much as possible is a requirement for
getting that deployment.

If that means moving some of the pain, even a disproportionate
amount of pain, onto those few, well motivated senders then that's
a good tradeoff.

>> The absence of a parent label check
>> thousands of DNS entries.

It's not unusual for them to have a deep DNS tree, either. A single
level tree walk will only benefit those enterprises who use shallow
DNS trees anyway.

>> The vast majority of enterprises make use of
>> Hence as things stand I expect ADSP to never be deployed,

I certainly don't expect it to be widely deployed by senders on  
arbitrary
existing domains. If there is widespread deployment I expect most
of it to be on customer-facing ecommerce and banking domains, not
existing enterprise domains. Really, cisco and similar corporations
are not particularly likely phishing targets.

>> and I request

If a sender isn't prepared to do the one-time effort to publish some
DNS records, then ADSP clearly isn't important to them.

Cheers,
   Steve

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 20:18:30 +0200

> Very few senders are going to care about or be able to use ADSP.

That is as much because of the effort that will be required as anything 
else.

> myriad MTA providers to implement efficient code to do so.

The myriad of MTA providers could do an additional query based on the 
absence of the record.
 
> amount of pain, onto those few, well motivated senders then that's

If you're wrong the protocol goes nowhere because of the myriad of 
senders who cannot deploy the record.  You are also binding the use of 
the record in such a way that mail systems will have to consider its 
absence meaningless far longer than otherwise.

> level tree walk will only benefit those enterprises who use shallow

It's one thing to special case each zone (typically where the deepness 
goes) or level (even if it isn't a zone split).  That's  O(log(entries)) 
and far more easily managed.

> are not particularly likely phishing targets.

We're not paypal but we see our fair share.  But the force and effect of 
your argument is that there will now be two classes of domains.  That is 
where I believe we are missing the mark.

> DNS records, then ADSP clearly isn't important to them.

IPv6 is a one time effort too.  One time costs matter too.

We're talking about many senders, and many provisioning systems – some 
of which are shoe string and bailing wire, others are C code, others are 
perl, some are products and others are free.  This will run the gambit 
from "easy to do" to "not for many years".  The effort you are talking 
about is in lots of code.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 May 2008 20:20:26 +0200

Dave Crocker wrote:
> ...  New insight, changed conditions, or the like.
>
> What has changed, Eliot?
>
> d/
>

John (and others - to be fair) have repeatedly mischaracterized as a 
tree walk a parent lookup.  The two are very different.  It is clear to 
me that confusion has ensued over precisely that point.  I stated this 
to John and then he repeated the false assertion.  Perhaps he thinks 
it's a small point - it is not.  John is correct to point out that some 
time ago there WAS a tree walk, but that has been gone for - well, quite 
some time.

Also, I specifically raised two issues that were not raised before.

To reiterate, the change the group has made introduces a strong 
dependency for enterprises on the DNS infrastructure in two separate 
ways.  It requires either those who want to authorize mail for 
provisioned hosts or those who want to prohibit mail from provisioned 
hosts to create a record for each host (either way) and the practical 
result is a dependency, therefore, on DNS provisioning infrastructure.  
Now it is true that mail systems already have a similar dependency.  
Here, however, because the dependency is created for even those hosts 
that are NOT authorized, the dependency is for a subsystem that is 
otherwise unrelated to a host's function (a higher crime IMHO).

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 May 2008 12:20:45 -0700

On May 27, 2008, at 11:20 AM, Eliot Lear wrote:

> tree walk a parent lookup.  The two are very different.

Inducing transactions against parent domains when receiving messages  
containing spoofed addresses (approaching trillions per day) involves  
a domain not otherwise associated with the service.  Suggestions that  
these domains can react by publishing bogus MX records as their means  
to mitigate the increased transactions is also impractical and  
outright unfair.  Such methods are based upon a desire to not impose  
any requirement upon Author Domain validity, except in the case where  
a sending domain asserts this desire.  Why not allow receiving hosts  
to decide whether non-SMTP message addresses are acceptable based  
solely upon positive evidence of SMTP being supported directly by the  
domain?  Don't inundate parent domains handling perhaps millions of  
sub-domains with non-terminated transactions regarding practices not  
within their bailiwick.

> It is clear to me that confusion has ensued over precisely that  
> point.  I stated this to John and then he repeated the false  
> assertion.  Perhaps he thinks it's a small point - it is not.  John  
> is correct to point out that some time ago there WAS a tree walk,  
> but that has been gone for - well, quite some time.

A journey of a thousand domains still starts with the first step.   
Even walking up one level can lead to similar problems as that of a  
walk up to the TLD.

On a similar topic regarding practicalities:

Publishing ADSP at every host can be simplified by eliminating the  
"_domainkey" prefix.  If a domain wishes to have a provider publish  
this record, it can delegate "_adsp.example.com" just as easily as it  
could delegate "_domainkey.example.com".  When a domain wishes to  
delegate a portion of their "_domainkey" domain, this will require  
ADSP records to be published separately anyway.  Injecting  
"_domainkey" above each ADSP policy record adds unnecessary overhead.   
There should not be an expectation that some third-party email  
provider will be able to satisfy this need for all hosts either.  As  
least delegating just "_adsp" domains for the purpose of publishing  
records at unused domains will not expose the domain to providers able  
to spoof signed email from these domains.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 May 2008 10:38:59 +0100

Hi Eliot,

I have to say that I don't see that as a new issue. I think that
this consequence was clear when we did the recent strawpoll - Jim
had explained it fully on the list as I recall.

If people who indicated a preference for removing the parent
check now speak up and say that they were confused, then I
guess we might want to revisit the issue.

If not, (and I've not seen any so far), then we should close
this.

Stephen.