[ietf-dkim] Underscore considerations

[Douglas Otis]

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:
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]@[any-subdomain.]signing-domain.tld

"user@*"
Matching user@[any-subdomain.]signing-domain.tld

"*@_"
Matching [any-user]@signing-domain.tld

"*@sub-domain_"
Matching [any-user]@sub-domain.signing-domain.tld

"*@*sub-domain_"
Matching [any-user]@[any-other.]sub-domain.signing-domain.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