[ietf-dkim] DKIM SSP: Security vulnerability when SSP record
does not exist?
ietf-dkim at kitterman.com
Wed Aug 24 11:14:56 PDT 2005
Douglas Otis wrote:
> On Aug 24, 2005, at 7:00 AM, Scott Kitterman wrote:
>> It seems to me that your proposed approach is anything but simple. It
>> would appear to me that you want to trade the direct, obvious, near- term
>> benifits of a defined deterministic Sender Signing Policy (I'm not
>> the current draft is perfect) for an uncertain, undesigned, and
>> undocumented automated abuse reporting infrastructure.
> A desire for "near term" email address protection is provided by S/ MIME
What is the standardized process by which a receiver can determine if a
sign using S/MIME? As a positive assertion S/MIME can be useful. I use
it when I think it appropriate. If there were some kind of a mechanism,
let's just call it perhaps a sender signing policy for the moment, that
would let me express a signing policy to mail receivers then I think
would bother to sign all my mail.
> By "near term" I assume you have some time frame in mind. What would
> that time frame be? What benefit, or limits to these benefits would
> there be? What exceptions will be needed? What exploits remain
> possible? What is required to administer this new mode? What email
> use behavior changes will be required?
Tomorrow would be fine with me. Waiting for the world to upgrade to
new, unwritten versions of MUAs to see benifit is not.
What you are asking is what won't SSP accomplish. It's difficult to
answer those questions before the design work is done. So lets quick
arguing about if it should be done. Get it done and see what it buys us.
>> You get to call this 'simple' from a DKIM perspective only by
>> declaring all
>> this complexity external to DKIM.
> Mappings of authorizations between various mailbox-domains and
> signing-domains will be expensive from an administrative and likely
> from a DNS standpoint. DKIM can become embroiled in debates about
> whether the From header is sacrosanct. The mailing list used to debate
> that topic would seem to mock such a view.
> Rather than depending upon administrators to tell their customers what
> they can no longer do (a bad idea), or receiving calls asking why email
> no longer works (another bad idea), there is another approach that does
> not run into these issues and yet provides _better_ protections.
> Because this approach involves less administrative overhead and imposes
> fewer restrictions, it should also be less expensive. I see expense as
> a significant impediment for deployment. This deployment would be over
> many years where expenses matter more than "near term" hype.
> Rather than creating a labyrinth of conditions each message must
> navigate, the signing domain may add an opaque-identifier to the
> message that relates internally to some static element (such as
> account). When there are no internal elements that can be used, this
> opaque-identifier could simply be sequential. This is done with an
> expectation that DKIM aware MUAs will be able to opportunistically bind
> the mailbox-address (both the routing and the pretty name), with the
> signing-domain, and this opaque-identifier. Binding approvals assume
> the recipient has reason to trust the message, and has been shown the
> elements being bound.
> The signing domain could suggest what level of binding is needed to
> protect the identity of the "author(s)". A large institution that
> restricts mailbox-address use for their domain, may indicate that only
> the mailbox-domain and signing domain needs to be captured within an
> MUA binding. Such a broad binding would encompass subsequent messages
> from that domain. When this assertion is seen by the MUA, and the
> mailbox-domain and the signing-domain match, then it should be safe for
> the MUA to automatically establish this binding. That leaves those
> attempting to spoof messages, where there has been prior
> correspondence, immediately identified as suspicious.
> When a key has been delegated, there should be a flag that indicates a
> lower level of trust, where the opaque-identifier should be derived by
> the key-selector and a binding exception made. Binding exceptions
> could be due to an innocent change that causes an alert of a suspicious
> message, where the user could be prompted with the binding details and
> asked whether to accept, merge, replace, ignore, or refuse. There
> would be no need to call the email provider to repair some relationship
> in DNS. Opportunistic identification can detect most cross-domain
> forgery, even when no restrictions are placed upon the mailbox-address
> Just by signing the message, the protective information can be
> transferred directly without expecting the use of any domain-wide
> assertions. The other use for an opaque-identifier (not related to any
> mailbox-address) would be to provide a means to deal with message
> replay abuse. This opaque-identifier also significantly aids
> correlation of abuse from a large domain. Zombies are a major issue,
> where those running zombies would be extremely adept at hiding within
> an authorization maze published within DNS. With an opaque- identifier,
> zombies will be readily apparent.
Pretty well making my point about complexity for me.
I'm not going to point by point go through that as there isn't anything
in your message you haven't said before.
I want SMTP time rejection of unauthorized messages. More/better
filtering is of little interest. The last thing I want is to require
end users to evaluate message authorization.
Oh, it turns out that if you want a DK aware MUA, you can already have it:
More information about the ietf-dkim