Mike,
I see two points:
1) This might fall under the same (relatively) recent debates in
IETF-SMTP surrounding what makes constitutes a "valid domain." In this
case, a valid client domain name (HELO) in new attempts to apply strict
SMTP compliance. Example:
HELO com <--- INVALID
HELO example.com <--- valid
HELO [example.com] <--- INVALID
HELO 1.2.3.4 <--- INVALID
HELO [1.2.3.4] <--- valid
So this probably suggest that DKIM base spec should document "d=" as a
MUST FQDN, with domain literals are not expected.
Borrowing some text from RFC 2821 Section 2.3.5, the DKIM d= description
can be updated to:
d= The domain of the signing entity (plain-text; REQUIRED).
| The domain name, as described in this document and in
| [RFC1035] is the entire, fully-qualified name (often
| referred to as an "FQDN"). This is the domain that
will be queried for the public key. This domain MUST be
the same as or a parent domain of the "i=" tag. When
presented with a signature that does not meet this
requirement, verifiers MUST either ignore the signature
or reject the message.
2) This is where SSP 3rd party signing restrictive policies would help.
If the 2822.From: domain is not the same (including multiple From:
consideration) as the "d=" domain then technically speaking, we have a
3rd party signature.
So using your "closer to home" example, as long as bankofamerica.com
uses an OA (original address) SSP restricting any 3rd party signing, you
would be protected from any such d=TLD abuse.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
----- Original Message -----
From: "Markley, Mike" <Mike(_dot_)Markley(_at_)bankofamerica(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, February 14, 2006 6:21 PM
Subject: [ietf-dkim] New Issue: TLD key publication and signing
Jim Fenton asked me to write a blurb on this after discussing it
with him at the DKIM conference in Santa Clara.
My understanding of the rules around the domain and the identity of a
message is that the identity (i=) must always be the same as the
domain (d=), OR a subdomain of it. Then, the public key published at
<selector>._domainkey.<domain> will be looked up.
I am not, however, aware of any mechanism for preventing a malicious
TLD
operator from publishing a key at _domainkey.<tld>. This suggests to
me
that it's quite possible for the operators of the TLD, whether that's
Verisign or some government-controlled agency, can then send mail with
d=tld and i=user(_at_)example(_dot_)tld, and that such a message's signature
would
validate. To hit closer to home, for me, a sufficiently ill-conceived
SiteMinder-like scheme by Verisign could permit them to send signed
mail
with the identity mike(_dot_)markley(_at_)bankofamerica(_dot_)com by signing
as d=com.
Obviously the TLD operators in most countries probably would not risk
the legal challenges to doing something like this, but it opens up
avenues of abuse where the TLD is operated by the government or,
potentially, even by a disgruntled key employee or agent of an
independent TLD operator.
This may simply be "as designed", but it is, IMO, worth documenting.
-- Mike
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html