Re: [ietf-dkim] Should DKIM drop SSP?

On Oct 26, 2005, at 9:17 PM, Earl Hood wrote:

> On October 26, 2005 at 19:11, Douglas Otis wrote:
>
> > There are vast numbers of messages legitimately sent by those not
> > identified in the From header.  Should these messages all be rejected
> > or deleted?
> >
> > The current SSP prohibition is exclusively based upon the email-
> > address found in the From header and is the _only_ means available to
> > repudiate messages from Bad Actors.
> > The impact of only allowing this the sole choice is significant  
> > and bad.
> It may help if you can provide example scenarios illustrating
> your points.  For example:
>
>   * Examples of legitimate messages sent by those not identified
>     in the From header.
>
>   * Examples showing how SSPs From-centric approach is bad.
>
> In general, giving examples provide a clearer understanding of the
> problem and how the problem can be addressed, especially when
> dealing with security issues.
>
> Many discussions are in the abstract, causing at times little progress
> being made on a particular topic since people's views of the topic
> may not be in sync.
I'll start from abstract concepts and then attempt to provide some  
examples.
----
The Current SSP "Only From" matters:

The Sender Signing Policy holds the email-address within the From  
header accountable for messages.  This overlaps attempts made by  
OpenPGP or S/MIME.  The negative side-effect of this effort is found  
when the relationship with the From email-address can not be directly  
verified and such messages are then rejected or deleted.  While  
OpenPGP and S/MIME were designed to establish a relationship with the  
author, DKIM is intended to operate at the MTA within the email  
message transport system which operates irrespective message headers.
In the extreme, and likely the coerced case, would be an assertion  
that all messages are exclusively signed by the From email-address  
domain.  This assertion of exclusivity is the _only_ mode that offers  
protection for the email-address.  When the reputation of the email- 
address is unfairly used as a basis for acceptance, there would be  
little actual choice afforded the email-address domain owner but to  
make this assertion.  These unfair reputation mechanisms are already  
in place, so get ready for some serious arm twisting.
Some providers may rejoice, but email-domains owners may find this  
most unpleasant as they have no means to monitor the providers.  In  
addition, an email-address becomes limited to a specific provider,  
and many services are now no longer practical. : (
----

When who signed matters (as it should be):

The Sender Signing Policy that attempts to hold the signer  
accountable would allow the extreme case to be asserted without  
causing messages to be deleted.  As such, those headers that identify  
the domain that "introduced" the message into email message transport  
system would be used to establish the assertions.  This could be the  
Resent-Sender, Resent-From, Sender, or finally the From header.  As  
there is no relationship that MUST be maintained with the From  
header, this would be in compliance with RFC2822 with respect to  
which domain _should_ be associated with the message.
As a result of being in compliance, there would be no messages  
unnecessarily deleted.  This assertion of "introduction" still allows  
repudiation of Bad Actors, but without negative consequences with  
respect to email delivery and the use of common services.  The  
assertion that all messages that have been "introduced" by the domain  
should also be signed by the domain would not be incompatible with  
most email services.  This mode does not assure the From header is  
never spoofed, but it does clearly establish when the source of the  
message is uncertain, who is accountable for the message, and permit  
identification of abusive sources by name.
A special case for "phishing" handled out-side of DKIM would be an  
assertion that additional "phishing" related protection is needed.   
An A record pointing to 127.0.0.3 found at the label  
"_phished.<example-domain> would be enough.  This assertion should be  
extremely simple for quick implementation, where the protection  
includes many more tests than just the From address and should not  
wait for DKIM.  There has not been a simple email policy proposal,  
and SSP is far from simple.  Adding complex parsing functions that  
must process a sequence of various types of DNS records can not be  
safely done in a hurry.
----


With the current SSP "Only From" matters proposal, regardless what  
assertions have been made for any From email address, when the  
signature is not an domain found within the message, the message is  
to be rejected or deleted.  This may obligate inclusion of a Sender  
header that may conflict with an existing header and cause support  
issues when dealing with complaints that messages are being altered  
in a manner that changes their appearance.  After all, appearance  
alteration was an objection made against OpenPGP and S/MIME.
When an email-address domain finds their _only_ means to protect  
their reputation is to apply the exclusively signed assertion, all of  
their messages sent from list-servers, e-invites, greeting-cards,  
etc. will be deleted or rejected.  This also prevents messages from  
being sent from other providers.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org