Subject: [ietf-dkim] New Issue: TLD key publication and signing

From: "Markley, Mike" <[email-masked]>
Date: Tue, 14 Feb 2006 15:21:35 -0800

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=[email-masked], 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-masked] 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

---

From: Mark Delany <[email-masked]>
Date: Tue, 14 Feb 2006 23:44:14 +0000

> I am not, however, aware of any mechanism for preventing a malicious TLD

Presumably a malicious TLD operator can also change what name servers
answer for your domain in which case they can completely assume your
identity as far as DKIM is concerned.

Mark.

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Feb 2006 00:54:51 +0100

Markley, Mike wrote:
 
> 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=[email-masked], and that such
> a message's signature would validate.

Hi, that sounds like a general "bug" or "feature" not limited
to TLDs, it would be the same with say ac.uk or navy.mil SLDs,
or any other domain with "independent" (zone cut) subdomains.

> Obviously the TLD operators in most countries probably would
> not risk the legal challenges to doing something like this,

Some TLDs are rather small, some have even an IP like "ordinary"
example.com domains.  I wouldn't bet that say "tv" is always
"better" than ordinary domains wrt to "independent" subdomains
(there must be a proper term for this case, please correct me.)

> This may simply be "as designed", but it is, IMO, worth 

Yes, but I'd say the general case has to be documented, it's
not limited to TLDs.
                             Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Feb 2006 16:29:02 -0800

On Feb 14, 2006, at 3:54 PM, Frank Ellermann wrote:
>> 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=[email-masked], and  
>> that such a message's signature would validate.
>
> Hi, that sounds like a general "bug" or "feature" not limited to  
> TLDs, it would be the same with say ac.uk or navy.mil SLDs, or any  
> other domain with "independent" (zone cut) subdomains.

This suggests the 'i=' feature is prone as there are no confirming  
label requirements similar to that used to define the boundary  
between the domain and the selector paths being a "_domainkey"  
label.  This is especially problematic as the selector may use  
multiple labels as well.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 14 Feb 2006 21:27:41 -0500

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-masked]>
To: <[email-masked]>
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.
>
> 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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 15 Feb 2006 20:23:03 +0100

>     HELO [1.2.3.4]        <--- valid

JFTR, that's state of the art 2821, maybe 2821bis will add
two cases:

      HELO cat.             <--- valid (trailing dot)
      HELO example.com.     <--- valid (dito)

And maybe 2821bis will allow to drop the funny ipv6 tag for
IPv6 literals.

> So this probably suggest that DKIM base spec should document
> "d=" as a MUST FQDN, with domain literals are not expected.

Possible.  Above all for ABNF lines like...

|  sig-d-tag       = %x64 [FWS] "=" [FWS] Domain

|  sig-i-tag =   %x69 [FWS] "=" [FWS] [ Local-part ] "@" Domain

...I expect to find a line "Domain =" modulo white space.  I'm
used to check ABNF elsewhere, please not also here.  Let's get
a proper import interface, all it takes is an ABNF line like...

   Domain = <as specified in RFC 2396>

...anywhere, and then I'd know that this can't be what we want,
because 2396 is obsolete.
                          Bye, Frank