Subject: [ietf-dkim] New Issue: overview doc could benefit from minor editing

From: "J D Falk" <[email-masked]>
Date: Tue, 18 Mar 2008 19:29:56 -0400

Suggested new language in [brackets], for various sections:

1.1.  DKIM's Scope

   DKIM signatures can be created by a direct handler of a message,
   either as its author or as an intermediary.  It can also be created
   by an independent service that is providing assistance to a handler
   of the message.  Whoever does the signing chooses the domain name to
   be used as the basis for later assessments.  Hence, the reputation
   associated with that domain name [may be] an additional basis for
   evaluating whether to trust the message for delivery.  The owner of
   the domain name being used for a DKIM signature is declaring that
   they accept responsibility for the message and may thus be held
   accountable for it.

[ . . . ]

   o  Does not protect against re-sending (replay of) a message that
      already has a verified signature; therefore a transit intermediary
      or a recipient can re-post the message [again] in such a way that
the
      signature would remain verifiable, although the new recipient(s)
      [may be different from those which were originally] specified by
the author.

1.2.  Prior Work

   Historically, email delivery assessment decisions have been based on
   an identity [derived from] the IP Address of the system that directly
sent
   the message (that is, the previous email "hop"), [RFC4408] or on the
   message content (e.g.  [RFC4406] and [RFC4407]).  The IP Address is
   obtained via underlying Internet information mechanisms and is
   therefore trusted to be accurate.  Besides having some known security
   weaknesses, the use of addresses presents a number of functional and
   operational problems.  Consequently there is a widespread desire to
   use an identifier that has better correspondence to organizational
   boundaries.  Domain names are viewed as often satisfying this need.

[ . . . ]

3.2.3.  Permit incremental adoption for incremental benefit

[ . . . ]

   Although it is envisioned that this mechanism will call upon
   independent services [(either within the receiving network, or a
   third party)] to aid in the assessment of DKIM results, they
   are not essential in order to obtain initial benefit.  For example
   DKIM allows (possibly large) pair-wise sets of email providers and
   spam filtering companies to distinguish mail that is associated with
   a known organization from mail that might deceptively purport to have
   the affiliation.  This in turn allows the development of "whitelist"
   schemes whereby authenticated mail from a known source with good
   reputation is allowed to bypass some anti-abuse filters.

[ . . . ]

   Management of email [delivery] problems currently represents a
   significant pain point for email administrators at every point on the
   mail transit path.  Administrators who have deployed DKIM
   verification have an incentive to evangelize the use of DKIM
   signatures to senders who may subsequently complain that [they
   believe] their email is not being delivered [as desired].

[ . . . ]

4.1.  The Basic Signing Service

[ . . . ]

   DKIM permits restricting the use of a signature key (by using s=) to
   signing messages for particular types of services, such as only for
   [a single source of] email.  This is intended to be helpful when
delegating signing
   authority, such as to a particular department or to a third-party
   outsourcing service.

[ . . . ]

4.2.  Characteristics of a DKIM signature

   A DKIM signature [applies to] the message body and selected header
fields.
   The signer computes a hash of the selected header fields and another
   hash of the body.  The signer then uses a private key to
   cryptographically encode this information, along with other signing
   parameters.  Signature information is placed into the DKIM-Signature
   header field, a new [RFC2822] header field of the message.

[ . . . ]

4.3.  The Selector construct

[ . . . ]

   Signers often need to support multiple assessments about their
   organization, such as to distinguish one type of message from
   another, or one portion of the organization from another.  To permit
   assessments that are independent, one method is for an organization
   to use different sub-domains in the "d=" parameter, such as
   "transaction.example.com" versus "newsletter.example.com", or
   "productA.example.com" versus "productB.example.com".  This is (or
   can be) entirely separate from the From: domain.

5.  Service Architecture

[ . . . ]

   The MSA  The MSA signs the message, using private information from
      the Key Store [(defined below}].

[ . . . ]

5.1.  Administration and Maintenance

   Reputation/Accreditation  If a message contains a valid signature,
      then the verifier can evaluate the associated domain name's
      reputation [in order to determine appropriate delivery or display
      options for that message].  Quality-assessment information, which
is associated
      with a domain name, comes in many forms and from many sources.
      DKIM does not define assessment services.  It's relevance to them
      is to provide a validated domain name, upon which assessments can
      be made.

[ . . . ]

5.4.  Unverified or Unsigned Mail

   Note that a failed signature [will in most cases cause] the message
to be treated in the
   same manner as one that is unsigned.  Messages lacking a valid author
   signature (a signature associated with the author of the message as
   opposed to a signature associated with an intermediary) can prompt a
   query for any published "signing practices" information, as an aid in
   determining whether the author information has been used without
   authorization.

--
J.D. Falk
Receiver Products
Return Path 

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 18 Mar 2008 21:13:05 -0700

> Suggested new language in [brackets], for various sections:

Unless I've misread the suggested changes, they appear to be word-smithing, 
rather than raising substantive issues.

I tend to find that people who put the energy into reading carefully enough to 
be able to make word-smithing changes usually make good suggestions.

Does anyone see a change they don't like?

d/

-- 

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 19 Mar 2008 10:29:07 +0100

> Does anyone see a change they don't like?

[old]
| a transit intermediary or a recipient can re-post the message
| in such a way that the signature would remain verifiable, 
| although the new recipient(s) would not have been 
| specified by the author.
[new]
? a transit intermediary or a recipient can re-post the message
? [again] in such a way that the signature would remain verifiable,
? although the new recipient(s) [may be different from those which
? were originally] specified by the author.

The old version is IMO clearer.

[old]
| Historically, email delivery assessment decisions have been based
| on an identity that used the IP Address of the system
| that directly sent the message (that is, the previous email "hop"),
[new]
? Historically, email delivery assessment decisions have been based
? on an identity [derived from] the IP Address of the system
? that directly sent the message (that is, the previous email "hop"), 

Both versions miss various important points, see issue #1556.

[old]
| A DKIM signature covers the message body and selected header fields
[new]
? A DKIM signature [applies to] the message body and selected header
? fields

>From my DEnglish POV "covers" is fine, no problem to change it.

[old]
[new]
? This is (or can be) entirely separate from the From: domain.

Statement aded at the end of 4.3, no problem.

[old]
| It's relevance to them is to provide a validated domain name, upon
| which assessments can be made.

s/It's/Its/  No problem with the [new] text, it also has "It's".

[old]
| Note that a failed signature causes the message
| to be treated in the same manner as one that is unsigned.
[new]
? Note that a failed signature [will in most cases cause] the message
? to be treated in the same manner as one that is unsigned.

Is that a conflict of "education" vs. "truth" ?  The [new] text
is certainly compatible with ID.kucherawy-sender-auth-header

 Frank

---

From: "J D Falk" <[email-masked]>
Date: Wed, 19 Mar 2008 14:24:50 -0400

Dave wrote:

> Unless I've misread the suggested changes, they appear to be
> word-smithing, rather than raising substantive issues.

Yep, that's why I put 'em all into a single issue.

I don't feel strongly enough about word-smithing to disagree with
Frank's points, but since he asked:

> [old]
> | Note that a failed signature causes the message to be
> treated in the
> | same manner as one that is unsigned.
> [new]
> Is that a conflict of "education" vs. "truth" ?  The [new] text is
> certainly compatible with ID.kucherawy-sender-auth-header

If the question you're asking is "is this signature valid?", then the
difference between no signature and a bad signature is generally
uninteresting except when debugging stuff.

But if the question you're asking is "is this message trustworthy?", the
difference (coupled with additional info, such as ADSP and reputation)
may turn out to be extremely important.  I say "may" because we don't
have a lot of real world experience yet.

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 20 Mar 2008 11:29:37 +0100

J D Falk wrote:

> If the question you're asking is "is this signature valid?", then
> the difference between no signature and a bad signature is generally

That POV is reflected in the old "educational" wording.

> if the question you're asking is "is this message trustworthy?",
> the difference (coupled with additional info, such as ADSP and
> reputation) may turn out to be extremely important.

And that's reflected in your proposal (and ID.sender-auth-header).

With Murray's results set your wording might be better, and some
folks here including me owe Hector an apology for the pushback
he got whenever he tried to talk about "bad" vs. "no" signature.

 Frank