[ietf-dkim] Draft summary of SSP functionality

[Steve Atkins]

On Dec 5, 2007, at 10:09 AM, Dave Crocker wrote:

> Folks,
>
> If non-participants are to be asked about the potential use of SSP,  
> it helps to have a description of it that is concise, complete and  
> for which there is reasonable consensus about the content.  Simply  
> handing non-participants a point to the specification is useless  
> for all but the most technical and dedicated.
>
> To that end, I've pulled some text from my review, as a candidate.   
> It's intent is not to judge SSP but to describe its salient basis  
> and functions. In other words, what is it, rather than is it good,  
> bad or broken?
>
> Obviously I have no expectation that my writing is entirely without  
> judgment, so I would like to get some working group review of the  
> text, to see if we can agree on text that is factual and useful:

This covers the mechanics of when and how an SSP record may
be queried. I think it also needs mention of what sort of assertions
an SSP record may make, in clear english

For example:

"This sender signs all mail with DKIM"

"This sender DKIM signs every third mail they send, except on  
Tuesdays (local time)".

"This sender requires that recipients discard any mail apparently  
from them that does not have a valid DKIM signature"

"This sender signs some mail with DKIM"

That sort of thing.

Cheers,
   Steve

>
>
>
>
> The IETF's DKIM working group has followed its specification of a  
> base method for associating a responsible identity to an email, via  
> cryptographic signing,
> with a draft, titled DKIM Sender Signing Practices (SSP).  The SSP  
> specification describes itself as defining a mechanism "senders may  
> use to
> advertise how they sign their outgoing mail, and how verifiers  
> should access
> and interpret those results." That is, SSP permits potential DKIM  
> signers to
> publish statements about how they use DKIM, and also to publish  
> directions for
> DKIM validators (receivers) on how they are to handle a class of  
> received
> messages.
>
> The SSP mechanism has a potential signer -- that is, the owner of a  
> domain name -- publish an SSP-specific DNS TXT record, in an SSP- 
> specific branch under the domain name.  On the receive-side, the  
> domain name under which the DNS query is made is taken from the  
> rfc2822.From <addr-spec> portion of an address, in a received message.
>
> By associating an organization's verifiable identity to a message, the
> reputation of that organization can then be used by a message  
> receiving
> engine, for determining message handling, such as whether to  
> deliver the
> message to the designated recipient.  This is what DKIM Base permits.
>
> By contrast, SSP seeks to detect misbehaviors, specifically related to
> unauthorized use of a domain in an RFC2822.From field <addr-spec>.   
> SSP does
> not seek to deal with other identity fraud, such as in the  
> RFC2822.From
> <display-name>, the Subject field, or in the message body, or any  
> use of "cousin" domains that can be confused with a target domain.
>
> The current SSP draft provides for two basic modes of use:
>
>    1. Unsigned message.  When a receiver gets a message that is not  
> signed, they can query the DNS for an SSP record, associated with  
> the domain name in the (first) rfc2822.From field header address.   
> If that record states that all mail with that domain name in the  
> From field is signed, then the recipient can assume that the  
> message is problematic.
>
>    2. Signed message.  When a receiver gets a message that is  
> signed, but which has the signature's "i=" that is different from  
> the domain name in the (first) From field address, perform the SSP  
> query, described in step 1. The result of this evaluation is  
> expected to override the reputation assessment of the actual signer.
>
> SSP is motivated by a desire on the part of message senders, to  
> inform message recipients about constraints on the senders'  
> practices.  The premise is that receivers with this additional  
> information will be able to reject a class of mail that is not  
> legitimate. The mechanism is approximate, in that a legitimate  
> message might begin with a legitimate signature, but then have the  
> signature get broken during transit.  When SSP is used, such  
> messages will be treated by the recipient as suspect.
>
> Given that adoption of a new mechanism, like DKIM's base signing,  
> takes many years, it should be assumed that use of SSP will almost  
> always result in a failed DNS query, for every message with a new  
> (un-cached) domain name in the From field.
>
>
> d/
> -- 
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net
> _______________________________________________
> NOTE WELL: This list operates according to http://mipassoc.org/dkim/ 
> ietf-list-rules.html