On Thu, 2006-06-08 at 18:56 -0700, Dave Crocker wrote:
Paul Hoffman wrote:
At 5:57 PM -0700 6/8/06, Douglas Otis wrote:
But this is the issue being discussed. These are serious security
concerns. There is zero containment of local-part namespace between
any subdomains. This too becomes a serious concern and is one of the
problems created. Even if a higher level domain wanted to do DKIM
safely, the MUA signing feature would be a disaster as a result of
this dubious feature.
The WG already accepted the feature after active discussion. Trying to
use the Security Considerations section to make the feature seem
"dubious" feels like an attack on the WG consensus process.
another view is that it is merely an attempt at some humor, since it is
difficult to imagine taking the concern seriously.
A private key intended for use at an MUA can not be constrained to
validate only a specific email-address domain as a direct result of the
'i=(_at_)subdomain' feature. Any use of a '_domainkey' subdomain by a higher
level domain therefore requires additional considerations. Would you
suggest this may require avoiding the use of an MUA based approach?
Spoofing should be a problem addressed by DKIM. This is significantly
jeopardized by an 'i=' subdomain convenience extensively employed by
spammers to obfuscate their domain with unverified and imaginary
subdomains within the signed 'i=' parameter. These unverified
components of the email-address domain weaken the concept that an
email-address is validated by DKIM. When the domain of the
email-address is uncertain, so is the local-part, irrespective of a 'g='
parameter within the key.
If this 'i=' subdomain feature is retained, then extensively warn about
what can go wrong when just trusting some higher domain to act beyond
existing delegation obligations. Do not naively depend upon these
details being in favor of the DKIM implementor. These issues need far
better clarification.
The latest Security Consideration section:
http://mipassoc.org/pipermail/ietf-dkim/2006q2/003830.html
did clarify that most Registry Operators are normally prohibited from
registering a name without a leading alpha character, but that is not
the end of the story. There are also cases to consider unrelated to how
DNS works with regard to delegation. In the case of DKIM, zones not
delegated to the email-address domain owner can dramatically affect the
operation of their email domain without having violated any delegation
arrangements.
Of course, this concern depends upon how seriously email-address
verification is taken. Email-address annotation will be hard pressed to
clarify which sections of an email-address domain have actually been
verified.
DKIM-Signature:
s=sales02; i=joe(_at_)accounts(_dot_)big-company(_dot_)com;
d=big-company.com; ...
<JOE(_at_)accounts(_dot_)BIG-COMPAY(_dot_)COM>
This annotation could mean accounts might be a fictitious domain, but
then there is internationalization to consider. Email filtering will
become more complex handling possible synthetic camouflage when needing
to block specific abusive accounts. While messages sent to abuse@ might
be used to get the key eventually withdrawn, an immediate solution is
also needed when communication with big-company.com is to be retained.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html