[ietf-dkim] Choices about Practice vs. Publication

[Douglas Otis]

On Jul 14, 2007, at 7:23 PM, Dave Crocker wrote:
> Michael Thomas wrote:
>> Dave Crocker wrote:
>>>     I think a simple and appropriate model, here, is that the  
>>> receive-side should be given information that permits it to  
>>> detect external attacks -- that is, misbehaviors by actors  
>>> external to the origin-side.
> ...
>> In which case, the bob and jane @ earthlink problem is really  
>> earthlink's to deal with. I think that's entirely appropriate; it  
>> is completely within earthlink's capability to, say, use SMTP AUTH  
>> to gate users to deal with this attack.
>
> You might be referring to a different issue, but I think the i=  
> parameter makes this particular issue moot.  Might have been an  
> interesting discussion about 2 years ago, but not so much now.

The i= provides an identity which may omit the local-part of the  
address on who's behalf the message is signed.  DKIM does not ensure  
this identity is meaningful in regard to the visual content of a  
message.   A key located within an email-address sub-domain  
represents a third-party signature.  In which case, the i= parameter  
is unable to identify an address within a parent domain that is  
likely recognized by the recipient.   However, the overview draft  
makes an assumption regarding the utility of sub-domain signatures.   
In doing so, this creates a new security concern.  What utility was  
envisioned by this suggestion?

In the draft-ietf-dkim-overview document,
---
1.3.3.  The Selector construct
...
  Signers do have the need for supporting multiple assessments about
  their organization, such as to distinguish one type of message from
  another, or one portion of the organization from another.  To permit
  assessments that are independent, an organization should use
  different sub-domains in the "d=" parameter, such as
  "transaction.example.com" versus "newsletter.example.com", or
  productA.example.com versus productB.example.com.

2.6.1.3.  Subdomain Considerations

  A Domain Name is the basis for making differential quality
  assessments about a DKIM-signed message.  It is reasonable for a
  single organization to have a variety of very different activities,
  which warrant a variety of very different assessments.  A convenient
  way to distinguish among such activities is to sign with different
  domain names.  That is, the organization should sign with sub-domain
  names that are used for different organizational activities.
---

RFC4871:

3.5.  The DKIM-Signature Header Field
...
d=  The domain of the signing entity (plain-text; REQUIRED).  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 (the
     signing identity, as described below), or it MUST meet the
     requirements for parent domain signing described in Section 3.8.
     When presented with a signature that does not meet these
     requirement, verifiers MUST consider the signature invalid.
---

Note: Section 3.8 conditionally permits valid signatures for sub- 
domain email-addresses only when not disabled by a flag within key  
records.

The DKIM overview makes a recommendation that did not receive much  
list discussion.  This appears to be based upon an assumption that  
sub-domain signatures could be considered authoritative for a parent  
domain within the realm of "assessments."  "Assessments" is a rather  
nebulous term.   Even parent domain signatures represent a risk  
partially addresses by RFC4871 #3.8.  Nothing within DKIM provides a  
means to limit sub-domain signature "assessments", as such signatures  
simply are not valid for parent domain email-addresses!

Allowing parent domain signatures is problematic from a security and  
complexity standpoint.  Suggesting that sub-domains can be used for  
"assessment" purposes invites a fair amount of abuse.   This means  
the 'i=' identity is unlikely to be meaningful to the email recipient  
as well.

Was sub-domain signatures considered to be a method to partition  
domains into differently vetted categories?  Was this to isolate  
sources where replay abuse may be less problematic?  There are  
security issues created by controlling message "assessments" by sub- 
domains.   This type of signature is not itemized within the SSP  
policy, nor can these types of signatures be explicitly controlled  
beyond outright prohibition of third-party signatures.  Prohibition  
of third-party signatures thereby prevents this utility.  Is this  
recommendation based upon there being an exception in the definition  
of "third-party" signatures?

A recipient can safely obtain assurances from a sub-domain signature  
by providing a by-name SSP authorization strategy.  A by-name  
authorization as provided in TPA-SSP can thereby limit the scope of  
third-party signatures.  The difference is rather stark, specifically  
when, as the overview suggests, there is a need for multiple  
assessments.

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.html
http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-01.txt

-Doug