On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote:
Douglas Otis wrote:
You wish to include an anti-forgery mechanism directly within DKIM. I
fear serious issues will likely derail DKIM deployment when "anti-
forgery" mechanisms interfere with normal email, while at the same time
forgery continues. I doubt there is a possible draft that offers
obtainable goals related to anti-forgery without per-user- keys.
Anti-forgery appears practical for S/MIME or OpenPGP, but becomes too
problematic for DKIM. At least when done directly.
The signature and SSP parts of DKIM are completely severable. Although
not perfect the current SSP draft would seem to offer a basis for more
optimism than that.
By optimal, this would be from a perspective that considers actions of
mailbox-address authorization to comprise a great portion of messages
rejected, rather than rejections due to other reasons. Retained in this
view is a belief that by authorizing email addresses, (and ignoring the
signing domain for example) then how the other 99% of the rejected
messages are handled matters less somehow.
Once it gets to the MUA, it's too late. I want to reject the message
during SMTP (after DATA, but before OK).
Your notion seems to consider mailbox address authorization will be the
principle mechanism used to reject messages, as far as signatures are
concerned. While that may sound good, I find it incredible. Do you
expect abusers to be that cooperative? More is accomplished with
expectations of good governance by those that sign email, than by
creating a matrix of authorization hurdles for mail administrators to
navigate. Abusers will nevertheless be the most adept.
After going through these efforts, incidence of mailbox-address
authorization failure will likely be infrequent. Adding a means for the
recipient to capture bindings based upon a message held in high
confidence, can be effective against targeted spoofing. An MUA captured
binding mechanism can check for pretty name collisions, as well as
checking against the mailbox-address. The MUA can even attempt to
detect character substitution schemes or drill down a list of known
exploits.
It seem rather than investing in the mailbox-address authorization
business, the real work will be at the MUA taking snap-shots of known
good message bindings. With this approach, an email administrator would
not need to be involved with DNS record updates every time some client
used a different provider or changed accounts.
If one is after an MUA solution, that may be true. However because of
the time requirements for an MUA solution, I think you end up backing
yourself into some kind of full fledged PKI infrastructure to support
post-facto signature validation.
This could work like self-signed certificates used to handle typical SSH
sessions. When there is no reason to believe things have changed, then
being prompted to save a new binding, which should also show the
accountable domain, provides an opportunity to mark this binding for all
future messages as good or bad automatically. The opportunity to spoof
someone would be rather remote with this type of semi-automatic
protection. If this were the case, do you really think there would be a
need to ensure the mechanism for the initial rejection in this case must
be optimal?
I expect that by constraining signature validation to the MTA/MDA and
passing a result to the MUA, an MTA/MDA approach would be much simpler,
lighter weight, and deployable. I don't expect you'll agree with this
either.
The details shared at the MUA are different. My concerns at the MUA are
with respect to claiming protection that is only half true. I would
rather see the first item shown to be the accountable domain. Then
claims regarding whether some address is valid becomes less critical.
Most would not expect a company to use a free email provider to sign
their mail.
Given that domain-wide assertions can prevent unauthorized servers, I
think that we would seriously be wasting an opportunity here if we
didn't provide that capability.
The details of where/when and how that is done (which seems to be our
major point of disagreement at this point) I would imagine are one
aspect of what the yet to be chartered working group is supposed to
figure out.
I don't think this is true. There are some appropriate domain-wide
assertions. I see advantages in using something like the CSA record, as
it provides a means to mitigate revocation protections and domain-wide
assertions, while also offering DoS protections. The SSP offers far less
and then muddles with mailbox addresses.
So, from a charter scope perspective, I would think that this aspect of
the problem should definitely be included.
The threats and the potential for DKIM to deal with the subset of these
types of threats that it does should also be included in the threat
assessment.
It would seem our biggest disagreement is where mailbox-authorization
schemes should reside. I would rather not muck with changing behaviors
and be more pragmatic about how security can be enhanced without placing
ever growing burden upon DNS and email administrators. DNS may face a
real challenge with DNSsec as well.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org