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
