I do not think it makes any sense to be publishing a policy that says
alsdkfjasdf.example.com is signed when no mail is going to ever be sent from
there.
We already have mechanisms to say alsdkfjasdf.example.com sends no mail, and
they block the attack without any need for complexity in the search scheme.
Defining a mechanism for nomail is out of scope, stating that we might rely on
existing nomail schemes is not. One of the reasons the group agreed that we did
not need to do nomail is that it is already done by SenderID/SPF.
I am saying that it makes no sense to kill ourselves creating a means of
specifying mail sending policy for domains that never send mail.
-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Tuesday, June 05, 2007 1:54 PM
To: Hallam-Baker, Phillip
Cc: Stephen Farrell; Scott Kitterman; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: I think we can punt the hard stuff as out of scope.
Hallam-Baker, Phillip wrote:
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
NOMAIL is out of scope, but wildcard is in scope.
The relevance here is that it looks like we can get 95% or
better coverage of the real use cases here by acknowledging that
wildcards are primarily an issue for NOMAIL.
It is? If I sign everything for my domain, I'd like to be
able to say
that for both the top level domain, and all of the subdomains too,
right?
Why would you be signing a subdomain that does not have an A record?
Come to that how does your understanding of DKIM policy
work for a node that has no A record, no MX record and no
related key records? If you have a policy 'I sign all mail'
what restrictions do you impose on the key records?
Huh?
Let's review the attack:
example.com: "I sign everything"
attacker sends mail purportedly from example.com. I look up
example.com, get the "I sign everything" record, I know it is
forged. All is good.
attacker then sends mail purportedly from
alsdkfjasdf.example.com. I look up policy for that node, and
find nothing. All is not good.
If I use a wildcard as well:
*.example.com: "I sign everything"
It will cover all subdomains *except* ones that have an RR
(usually an A record). Thus, we need something that covers
those nodes too. Hence the tree walk, forcing those nodes to
have the policy RR there too, etc.
I don't understand what you wrote above has to do with this attack.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html