ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Draft summary of SSP functionality

2007-12-05 18:30:39
Perhaps we need a better introduction in the specification, then.  The
text below isn't worded from the standpoint of a document introduction,
but it might help fill the vacuum created when the normative text in the
introduction gets moved elsewhere.

Comments below...

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:




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.

It's not really an SSP-specific branch, but an SSP-specific label under
the DKIM key management branch.


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.

That's one way to look at it.  I would describe it, instead of "detect
misbehaviors, ..." as "provide guidance to DKIM verifiers regarding
messages lacking a valid DKIM signature on behalf of the message's author."

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.

s/different from the domain name/different from the/  if you want to
match the current SSP draft.  Where did you get the second sentence? 
The term "reputation" occurs exactly once in the draft and it isn't
saying this.


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.

Rejecting messages is just one possible result.  Placing that first
emphasizes it, in my opinion inappropriately.  What you fail to mention
is that there are domains who would like precisely this to happen:  if
their message gets broken, even inadvertently in transit, they want it
rejected.

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.

This is a true statement, but not something that I think needs to be in
an introduction to the technology.  There are lots of things that result
in failed DNS queries (IPv6 AAAA requests come to mind), and that
doesn't seem to be a problem.

-Jim
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html