As an ISP we route customer mail thru our mta's, we have business customers
that may use their own mta's. If a customer determines that entity at foo.com
wishes to use use bar.com's mta are you saying that bar.com should not sign on
foo.com's behalf? Will that no present a problem with the reception of
foo.com's mail down stream when dkim sigs are expected everywhere? How do we
resolve that?
thanks,
Bill
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of Jim Fenton
Sent: Wed 4/12/2006 8:35 PM
To: IETF-DKIM
Cc: Peter Koch
Subject: [ietf-dkim] New issue: Signing by parent domains
This issue derives from a conversation I had with Peter Koch at the end
of the week in Dallas.
In -base, section 3.5, the description of the d= tag allows the domain
of the signing entity to be a parent of the signing address itself. In
other words, d=example.com and i=user(_at_)sub(_dot_)example(_dot_)com is
legal. This
was done largely as a convenience; it allows domains to sign using keys
at the higher domain level when they employ subdomains to aid mail
routing, rather than having to publish key records in each subdomain.
This gives rise to the attack described in -threats section 4.1.18, "Key
Publication by Higher Level Domain". On one hand, this isn't a very
worrisome threat, since domains need to trust the publisher of their NS
records. But it's possible to construct situations where this might be
a bigger concern. For example, a higher level domain, not under the
same administrative control as its subdomains, starts signing messages
it sends on its own behalf, and a key is compromised. All of a sudden
the subdomains are vulnerable too. The problem is that there's no way
to tell where the administrative boundaries are between levels in the
domain hierarchy.
The solution to this would be to remove the language in section 3.5, "or
a parent domain of", and the threat goes away.
It seems like a small benefit we're getting through "parental" signing,
offset by a small threat. How do others feel about this?
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html