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" <[EMAIL PROTECTED]>
To: <[email protected]>
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 [EMAIL PROTECTED], 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 [EMAIL PROTECTED] 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
