[ietf-dkim] ISSUE 1525 -- combine Arvel's, Doug's,
and John's ideas (?)
deepvoice at gmail.com
Tue Jan 22 06:52:30 PST 2008
On Jan 19, 2008 4:15 PM, Douglas Otis <dotis at mail-abuse.org> wrote:
> On Jan 18, 2008, at 11:53 PM, Frank Ellermann wrote:
> > Douglas Otis wrote:
> >> There is a domain within the signature that should be used to
> >> assess compliance. What prevents a valid signature of the From
> >> domain from allowing a message to comply with "all" or "strict"?
> > The most interesting case for SSP is "no signature".
> SSP should create compliance requirements for messages based upon From
> header's domain(s). A "strict" or "all" compliance requirement
> should be met with a signature that could be valid for the From email-
> address's domain. The signature should not need to be "on-behalf-of"
> the From email-address (as determined by the signatures i= parameter).
> IMHO there should be an exception for restricted keys, where these
> signatures must be on-behalf-of the From email-address to fulfill a
> compliance requirement of "all" or "strict".
> > For my unconvincing "toss a coin" list (Message-ID or first author
> > or Reply-To) it's of course possible to add "use any signature for a
> > domain in From addresses" to figure out a relevant domain for SSP.
> It should not matter which header a domain's signature is on-behalf-
> of. DKIM is not about establishing an author's identity. The trust
> being established is with the signing domain. The signing domain has
> the option of using ambiguous signature (no i= or no local-part and
> multiple email-addresses of their domain). IMHO, the signing domain
> should be able to even use an opaque identity that does not associate
> with any header. An opaque id could prove useful to protect someone's
> privacy. A domain should be able to indicate they sign "all" without
> conveying anything more than that it was signed by their domain.
> > But that only works if there is a corresponding DKIM signature, when
> > it's not really necessary to test SSP.
> Just having a DKIM signature is not enough. Domains protected by DKIM
> and an SSP assertion of "all" or "strict" must include a signature
> from a domain that would be valid for the From email-address domain in
> question. The DKIM WG seems unnecessarily focused on the on-behalf-of
> feature of the DKIM signature. This feature _might_ enable an MUA to
> highlight which identity the signature was on-behalf-of. There may be
> cases where it is not possible for MUAs to establish which identity
> the signature was on-behalf-of. In that case, just the signature
> domain could be highlighted. Due to the possible on-behalf-of
> uncertainty, DKIM signature notifications must be able to convey just
> the domain of the signature.
> Although compliance for "all" or "strict" could be defined to require
> an unambiguous on-behalf-of, such a requirement will make unambiguous
> on-behalf-of less certain. The signing domain might then "falsify"
> the on-behalf-of to meet an unambiguous on-behalf-of. Security
> concerns are better met by not placing constraints on the types of
> signatures used. There are also the issue of body length, and subject
> lines where security might be impacted. The verifier/MUA can use the
> information and display whatever they consider appropriate. One could
> argue that excluding the subject line and including body length should
> not be used as well. There is no reason to use SSP as a means to
> constrain these parameters.
> > Or do I miss something obvious in your proposal ? We could pick
> > John's proposal where Arvel's idea doesn't work, just look at all
> > domains in From addresses, for legit mail it's rare. That needs
> > some "SSP processing limits" for malicious mails (not as badly as
> > for SPF).
> EAI might wish to allow two From email-addresses to permit alternative
> formats. SSP could assert that messages containing more than two From
> email-addresses are not complaint with "all" or "strict". This would
> limit the number of policy search operations to two per message.
> Except in cases of restricted keys, SSP compliance should not depend
> upon which header the address is on-behalf-of. Ensuring an
> unambiguous signature is within the control by the signing domain and
> is independent of SSP compliance. MUAs are free to display
> ambiguously signed, body length, and excluded subject line messages in
> any manner they consider appropriate. There is no reason for the DKIM
> WG to dictate how the on-behalf-of feature of the signature must be
> used before a domain can assert their signing practices or policies.
> Let the market decide.
I liken this ~entire~ argument to something as asinine as not selling
right-handed golf clubs because there are a lot of left handed people
out there. Fringe cases should be considered only as to whether or not
we should add an asterisk to the suggested usage page.
More information about the ietf-dkim