ietf-dkim
[Top] [All Lists]

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

2007-12-05 19:38:30
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.

What does it mean to have an SSP-specific label that is not an SSP-specific
branch?


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:

You don't think that a status label of "suspicious" implies a focus on
misbehaviors?

-base is careful to say that there is no semantic to be taken from the absence
of a valid signature.  -ssp is explicitly for the purpose of creating
semantics about the absence of any signature or an acceptable signature.

As for "detecting" versus "providing guidance" these focus on very different
levels, which I guess I think are are complementary. The former is higher
level, IMO, while the latter is more about the mechanism.  The text discusses
things in terms of their basic thrust.  There is a conceptual difference
between the nature of the use of DKIM signing versus SSP.


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

If I did the specified edit properly, that produces:

    When a receiver gets a message that is signed, but
    which has the signature's "i=" that is different from the
    in the (first) From field address...

I assume the point of the edit is to include full addresses.

On reading the result, I'm inclined to suggest "...signature's i= value that
is different..."


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.

Do envision a reasonable scenario where a receiver has adopted SSP and
conforms to it, but does not have the stated sender enforcement request
override the reputation assessment for a signer?  Note that this either
implies or explicitly violates the request of the SSP domain owner.

Could you provide some examples of such scenarios?


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

The section 2.9 text "a Verifier may decide the message should be accepted on
the basis of other information beyond the scope of this document" at first
seems to support your view, but I think a bit of reflection changes that.

While the text explicit notes that rejection is not the only action that can
be taken, the language actually assumes that it will be typical and that an
outcome other than rejection is, frankly, exceptional.

Some of this depends on just how pragmatic and honest we want to be in stating
what the goals of SSP publishers actually are and what the likely practices of
receivers who adopt SSP will be.

If the summary is to achieve the goal of meaningfully help others to
understand the "nature" off SSP then the text needs to have more than
mathematical purity of diplomatically and formally careful specification
language.  It needs to broach issues of motives and expected uses.


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.

I think that some of these concerns get taken care of by expanding the text to
explicitly list the range of assertions that Steve Atkins suggested.


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.

Why?  A factually correct statement about performance and utility of a
technology is typically considered to be a reasonable part of a summary for it.


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.

Your comment suggests that a lengthy discussion is needed about the nature and
import of particular protocol behaviors.  For now I will leave it at noting
that patterns of DNS query failure have a long history of being considered to
be important.

At base, you seem to be suggesting that statements about overhead and failures
isn't all that important.  My view is that it is necessary to know such things
in order to formulate a proper opinion about the mechanism.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html