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
