ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] protecting domains that don't exist

2008-04-28 07:55:08
On Mon, Apr 28, 2008 at 12:53 AM, Jim Fenton <fenton(_at_)cisco(_dot_)com> 
wrote:

 >> Similar concerns led the WG to the use of TXT records rather than a
 >> new RR.
 >
 > Not really. The infrastructure barrier to support of a new RR exists
 > with both those who create the record as well as those access it.
 >
 > The barrier for ADSP is only with those who create the record.  Very,
 > very different dynamic.

 Agree that ADSP requires changes only on the publication side. I still
 believe that this introduces a significant barrier.



 >>     There are a lot of DNS management tools out there that would need
 >> to change in order to publish the necessary ADSP records, and this
 >> would take considerable time.
 >
 > They already need to change, to support one record (for one domain.)
 > How is there something fundamentally worse about having to support many?

 The tools don't need to change; the additional TXT record for ADSP can
 just be published independently using existing tools.

 We have two approaches to this problem, one approach which requires more
 effort on the part of ADSP publishers (either manual publication of
 additional records or deployment of new DNS tools), and one approach
 that requires more effort on the part of ADSP users, although that
 effort is largely contained within the software implementing ADSP and
 transparent to the deployer. Let's just treat this as an engineering
 tradeoff.

 I'm rather surprised this has become such an issue for you and John
 since this same approach is used in draft-levine-asp-00, which John
 edited and on which you collaborated.

I don't grasp the technical bits to provide a coherent explanation of
how to do what I want. But I have to say, without any sort of domain
blanket/coverage option, it seems like something is really missing
here. Without any sort of assumption or ability to limit what's
allowed under spamresource.com, I think ADSP is much less useful. My
concern is that if I can't restrict or cause failures automatically
outside of a specific subdomain or host, it does me little good to
sign on signed.spamresource.com when a phisher can fake
signed2.spamresource.com and not automatically be failed by checking
sites.

If I'm understanding the issues at hand. The thread is a bit difficult
to follow. I gather from some friendly offlist explanation that Jim
advocates a domain-wide signing policy that would go 1-2 sublevels
deep and no deeper. Jim, is that basically correct? I'd love an
example or two of how this works with 1-2 level deep signed and
spoofed fqdns, and what happens with levels deeper (no opportunity for
DKIM? or ADSP?)

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