Subject: [ietf-dkim] Draft summary of SSP functionality -v2

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Dec 2007 21:36:03 -0800

Folks,

Here is a revised version of the SSP Summary Description, based on comments
received:

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.
The new specification is for 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 permits a potential signer -- that is, the owner of a domain
name -- to publish an SSP-specific DNS record -- a 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 author's mailbox
address -- 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 the email address in a message's RFC2822.From field
<addr-spec>.  SSP does not seek to deal with other identity fraud, such as in
the human-readable 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.

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 detect, and
possibly reject, a class of mail that is not legitimate. At best, the
mechanism is approximate, in that a legitimate message might begin with a
legitimate signature that becomes broken during transit. When SSP is used,
such messages will be treated by the recipient as exceptions.

The current SSP draft provides for two basic conditions which will trigger a
query:

    1. Unsigned message.  When a receiver gets a message that has no DKIM
signature, they can query the DNS for an SSP record that is associated with
the domain name in the (first) rfc2822.From field header mailbox address.

    2. Signed message.  When a receiver gets a message that is signed, and
lists one identity in the signature's i= parameter -- the identity on behalf
of which the message is signed -- but another in the (first) address in the
 From field, then perform the SSP query, described in step 1.

The publisher of an SSP record can say that:

    1. All mail that they send is signed by them

    2. All mail that they send is signed by them and they do not send mail via
intermediaries -- called "third parties" -- such as mailing lists that may
modify and re-sign the message.

Messages that fail an SSP analysis are handled as exceptions. The publisher of
an SSP record may request that such mail be treated to:

    1. Further consideration, where the exceptional status is only one factor
in determining handling.

    2. Rejected.

SSP also permits the publisher to declare that the record applies to all of
its sub-domains, although there is a DNS limitation on reconciling deeply
nested sub-domains with this record.

The SSP specification defines a 10-step "check procedure" that is a decision
tree for performing SSP analysis.

As an example of implications, the SSP rejection semantics would mean that a
SSP-conformant receiving site would reject a message that has a broken author
signature,even if it still had a valid signature by an operator with a good
reputation. SSP is likely to have a number of other interactions with email
handling practice.

Given that adoption of a new mechanism like DKIM's base signing takes many
years, adoption by any arbitrary sender/receiver pair is unlikely for many
years, absent prior arrangement.  So most publishers of SSP records will be
sending to sites that are not checking them.  Equally it should be assumed
that receivers will almost always obtain a failed SSP 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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Dec 2007 11:33:52 +0000

Folks,

I think we've enough to be doing to process the current
set of issues with SSP without taking on additional
work to get consensus on text like this.

So, by all means develop a summary, but unless its
intended to put it in the SSP I-D, this is not something
where we expect or need WG consensus, so it'd maybe be
better to do it on say some DKIM marketing list rather
than take up cycles here, or else to wait until we've
resolved most of the issues and the list is quieter.

Thanks,
S.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2007 05:42:15 -0800

> resolved most of the issues and the list is quieter.

Stephen,

I am asking for feedback.  I didn't ask for it to be a working group item or 
for consensus.

The document attempts a factual description of SSP.  With references like 
"rfc2822.From" it rather clearly is not a "marketing" document.

You might have noticed that there is some disparity of views about basic 
aspects of SSP and even about SSP's purpose.  You might also have noticed that 
some holders of views strongly disagree with my own.

The first point should worry a working group chair about the basic credibility 
of claiming working group consensus on the specification. One would think that 
a working group chair would welcome an exchange that might ensure commonality 
of understanding about basic aspects of SSP facts.

The second point should makes it useful for me to gather comments from this 
list, before I circulate a purportedly factual description of SSP to others.

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Dec 2007 13:46:46 +0000

Dave Crocker wrote:

> I am asking for feedback.  I didn't ask for it to be a working group
> item or for consensus.

Understood.

> The document attempts a factual description of SSP.  With references
> like "rfc2822.From" it rather clearly is not a "marketing" document.

IMO its in-between.

> aspects of SSP and even about SSP's purpose.  You might also have
> noticed that some holders of views strongly disagree with my own.
> 
> The first point should worry a working group chair about the basic
> credibility of claiming working group consensus on the specification.
> One would think that a working group chair would welcome an exchange
> that might ensure commonality of understanding about basic aspects of
> SSP facts.

Yes. That's why I'd rather that we focus on the document, not on
external text. If you were proposing new text for the introduction
then it'd be right on the mark, as-is, I worry that it'll be
distracting.

> The second point should makes it useful for me to gather comments from
> this list, before I circulate a purportedly factual description of SSP
> to others.

Fair enough to do that, after we have WG consensus. For now, its
a little premature.

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2007 06:17:01 -0800

>> like "rfc2822.From" it rather clearly is not a "marketing" document.

What does that mean?  What portions or aspects of it qualify as 'non-technical 
marketing'?

> then it'd be right on the mark, as-is, I worry that it'll be

I'll repeat:  You have a working group that has demonstrated a widely 
divergent understanding of what SSP is.  That tends to undermine claims of 
real working group consensus.

You ought to welcome an exercise that could facilitate convergence of basic 
points.

> Fair enough to do that, after we have WG consensus. For now, its

You think that formulating a summary statement of facts, after a couple of 
years of effort and just before Last Call is somehow premature, particularly 
when the lack of working group consensus on core decisions seems pretty evident?

d/
-- 

   Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Dec 2007 14:56:15 +0000

Dave Crocker wrote:
>> IMO its in-between.
> 
> What does that mean?  What portions or aspects of it qualify as
> 'non-technical marketing'?

I assume its aimed at a less technical audience.

> divergent understanding of what SSP is.  That tends to undermine claims
> of real working group consensus.
> 
> You ought to welcome an exercise that could facilitate convergence of
> basic points.

Sure. If you wanted to recast the text as an alternative to the
current introduction of the I-D, then I'd welcome the effort.

Right, now I don't think that working on two different descriptions
of the same thing on the same list is a good idea.

> You think that formulating a summary statement of facts, after a couple
> of years of effort and just before Last Call is somehow premature,
> particularly when the lack of working group consensus on core decisions
> seems pretty evident?

I think that writing such external text would be much more likely
to be useful (and lead to a more a accurate result) after we've
processed the issue in our tracker.

S.

---

From: <[email-masked]>
Date: Tue, 11 Dec 2007 10:12:47 -0500

A few suggested changes

"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."

Revised 

That is, SSP permits potential DKIM signers to
publish statements about how they use DKIM, and also to publish a policy
guideline for the DKIM validators to assist in further message
processing
*****************************************
"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."

Revised

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.
*****************************************
Delete the following section as SSP doesn't detect anything, just
advises receivers about sender policy

By contrast, SSP seeks to detect misbehaviors, specifically related to
unauthorized use of the email address in a message's RFC2822.From field
<addr-spec>.  SSP does not seek to deal with other identity fraud, such
as in
the human-readable 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
*******************************************

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Tuesday, December 11, 2007 12:36 AM
To: [email-masked]
Subject: [ietf-dkim] Draft summary of SSP functionality -v2

Folks,

Here is a revised version of the SSP Summary Description, based on
comments
received:

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.
The new specification is for 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 permits a potential signer -- that is, the owner of a
domain
name -- to publish an SSP-specific DNS record -- a 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 author's
mailbox
address -- the rfc2822.From <addr-spec> portion of an address -- in a
received
message.

By contrast, SSP seeks to detect misbehaviors, specifically related to
unauthorized use of the email address in a message's RFC2822.From field
<addr-spec>.  SSP does not seek to deal with other identity fraud, such
as in
the human-readable 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.

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 detect, and
possibly reject, a class of mail that is not legitimate. At best, the
mechanism is approximate, in that a legitimate message might begin with
a
legitimate signature that becomes broken during transit. When SSP is
used,
such messages will be treated by the recipient as exceptions.

The current SSP draft provides for two basic conditions which will
trigger a
query:

    1. Unsigned message.  When a receiver gets a message that has no
DKIM
signature, they can query the DNS for an SSP record that is associated
with
the domain name in the (first) rfc2822.From field header mailbox
address.

    2. Signed message.  When a receiver gets a message that is signed,
and
lists one identity in the signature's i= parameter -- the identity on
behalf
of which the message is signed -- but another in the (first) address in
the
 From field, then perform the SSP query, described in step 1.

    2. All mail that they send is signed by them and they do not send
mail via
intermediaries -- called "third parties" -- such as mailing lists that
may
modify and re-sign the message.

Messages that fail an SSP analysis are handled as exceptions. The
publisher of
an SSP record may request that such mail be treated to:

    1. Further consideration, where the exceptional status is only one
factor
in determining handling.

    2. Rejected.

SSP also permits the publisher to declare that the record applies to all
of
its sub-domains, although there is a DNS limitation on reconciling
deeply
nested sub-domains with this record.

The SSP specification defines a 10-step "check procedure" that is a
decision
tree for performing SSP analysis.

As an example of implications, the SSP rejection semantics would mean
that a
SSP-conformant receiving site would reject a message that has a broken
author
signature,even if it still had a valid signature by an operator with a
good
reputation. SSP is likely to have a number of other interactions with
email
handling practice.

Given that adoption of a new mechanism like DKIM's base signing takes
many
years, adoption by any arbitrary sender/receiver pair is unlikely for
many
years, absent prior arrangement.  So most publishers of SSP records will
be
sending to sites that are not checking them.  Equally it should be
assumed
that receivers will almost always obtain a failed SSP DNS query, for
every
message with a new (un-cached) domain name in the From field.

d/
-- 

   Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 11 Dec 2007 08:47:41 -0800

> I assume its aimed at a less technical audience.

I do not know why you assume that.

It's aimed at participants in this working group and non-participants.  All 
are intended to be technical, such as the broad audience of email anti-spam 
operators.

> current introduction of the I-D, then I'd welcome the effort.

The goals of an Introduction and a Technical Design Summary are different. The 
working group has done an excellent job of demonstrating its need for the latter.

> of the same thing on the same list is a good idea.

They aren't "different".  They should be complementary.

> processed the issue in our tracker.

Let's wait until we are done before having any summary text that we can 
circulate broadly for feedback about the work?

Interesting model of public vetting.

d/

-- 

   Dave Crocker