[ietf-dkim] protecting domains that don't exist

[Eliot Lear]

Steve Atkins wrote:
> It doesn't contain any operational justification or goal for
> SSP. It describes what (one person) wants from SSP, it
> does not explain why, and it definitely doesn't provide the
> operational problem that SSP is intended to mitigate.
>   


Well, I really don't know where to begin.  Here's the text.

>    DomainKeys Identified Mail [RFC4871] defines a message level signing
>    and verification mechanism for email.  While a DKIM signed message
>    speaks for itself, there is ambiguity if a message doesn't have a
>    valid first party signature (i.e., on behalf of the [RFC2822].From
>    address): is this to be expected or not?  For email, this is an
>    especially difficult problem since there is no expectation of a
>    priori knowledge of a sending domain's practices.  This ambiguity can
>    be used to mount a bid down attack that is inherent with systems like
>    email that allow optional authentication: if a receiver doesn't know
>    otherwise, it should not assume that the lack of a valid signature is
>    exceptional without other information.  Thus, an attacker can take
>    advantage of the ambiguity and simply not sign messages.  If a
>    protocol could be developed for a domain to publish its DKIM signing
>    practices, a message verifier could take that into account when it
>    receives an unsigned piece of email.

Put another way, you can't tell the difference between "doesn't use 
DKIM" with "this is a forged message" without either SSP or some 
out-of-band (and unmentioned) mechanism.  If you're asking for more 
specifics about what YOU should do with a message once it's determined 
to (a) not have a valid signature and (b) have a policy of signing all 
messages, I'm afraid that Dave and others have befuddled this group into 
thinking that's a bad idea and somehow out of scope.

Eliot