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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html