[ietf-dkim] Underscore considerations
dotis at mail-abuse.org
Sun Jun 11 15:36:59 PDT 2006
On Sun, 2006-06-11 at 00:28 -0400, Bill.Oxley at cox.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:
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
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
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
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.
More information about the ietf-dkim