On Sun, 2006-06-11 at 00:28 -0400, Bill(_dot_)Oxley(_at_)cox(_dot_)com wrote:
At this point I tend to support Doug's position that we "allow"
wildcard entries on both sides of the "@" to delimit abuse.
I assume this refers to the base-02 //g= template suggestion:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003762.html
This proposal differs from John's by not requiring an additional tag be
included to conditionally extend constraints of the 'g=' tag.
The 'g=' tag syntax is extended by allowing inclusion of the '@' symbol,
and the '_' character representing the domain containing the
"_domainkey" label.
Wildcarding is then allowed on both sides of the '@' symbol for
expansion of the template to match an email-address being annotated as
being assured as "properly" used by the signing domain. Examples might
include:
"user*",
Matching user[-stuff](_at_)[any-subdomain(_dot_)]signing-domain(_dot_)tld
"user(_at_)*"
Matching user(_at_)[any-subdomain(_dot_)]signing-domain(_dot_)tld
"*(_at_)_"
Matching [any-user](_at_)signing-domain(_dot_)tld
"*(_at_)sub-domain_"
Matching [any-user](_at_)sub-domain(_dot_)signing-domain(_dot_)tld
"*(_at_)*sub-domain_"
Matching
[any-user](_at_)[any-other(_dot_)]sub-domain(_dot_)signing-domain(_dot_)tld
----
Caveat
Use of templates for validating email-addresses, especially within the
right-hand portion of the email-address, reduces security. The intent
is to convey an explicit assurance made by the signing domain. When an
assurance of proper email-address use is conveyed by a match to a
partial template within the 'i=' parameter, email-address annotations
must also be confined to headers contained within the message signature.
When sub-domains are included within the 'i=' parameter, domain specific
constraints are hidden by being present only within the key. A log of a
key related sub-domain qualification will likely not be recorded. It
should also be noted that the 'g=' template information, although
critical to security, is neither signed nor logged by way of captured
signature header information and verification results.
Use of email-address templates offering expansions within both left and
right hand portions of the email-address offer little in the way of
security. It is likely 'i=' or 'g=' use of the '@' and '_' expansions
will be problematic with respect to consistent validation annotations as
there are multiple methods to convey similar restrictions.
A simplified alternative:
A generally safer and more conservative approach would only allow either
the complete local-part or nothing to appear in either of these
parameters, and therefore disallow use of virtual sub-domains. When an
MTA wishes to employ a common private key for signing all sub-domains,
where email-address within these sub-domains are also to be validated, a
copy of the public key is published at each of these validated
sub-domains.
The impact of this simplification:
A compromised key will never affect the validation of email-addresses
using sub-domains below where the key is published. The domain
validating the email-address will always be obvious to the recipient. A
compromised key can also be blocked by an entry of a single address in a
simple form. The 'g=' parameter can return to being compatible with
that of DomainKeys.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html