Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?
2005-08-24 11:18:54
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
saying
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
now.
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
use.
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:
https://addons.mozilla.org/extensions/moreinfo.php?application=thunderbird&category=Message%20Reading&numpg=10&id=345
Scott Kitterman
_______________________________________________
ietf-dkim mailing list
http://dkim.org
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Scott Kitterman
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Douglas Otis
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?,
Scott Kitterman <=
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Douglas Otis
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Scott Kitterman
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Douglas Otis
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Scott Kitterman
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Douglas Otis
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Dave Crocker
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Douglas Otis
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Dave Crocker
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Douglas Otis
- Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?, Scott Kitterman
|
|
|