Subject: [ietf-dkim] Comments on draft-ietf-dkim-deployment-04

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 13 Apr 2009 15:13:53 -0700 (PDT)

I've been pretty thorough here, with an eye toward having it ready for the 
RFC editors.  Anything starting "-" is a nit about form or grammar (there 
are lots), and anything else is about substance (there are some).

GENERAL COMMENTS

There's normative language in here.  Is that appropriate, proper, etc. for 
an informational document?

1. Introduction

Suggested text for the "anchor2" annotation, essentially punting it out 
of the introduction:

   The possibility of use of DKIM results to develop a local reputation
   database is also discussed.

2.1 A Systems View of Email Trust Assessment

- period should be outside the parentheses at the end of the first 
paragraph

- same nit, first sentence of second paragraph

- last two sentences of the second paragraph should be merged with a comma 
(i.e. "... of the associated identifier, whereas a stream ...")

- in "...the content cited in the DKIM-Signature: field's h= tag have 
been...", change "have" to "has"

2.2. Choosing a DKIM Tag for the Assessment Identifier

There is discussion here which I find may be in conflict with the erratum 
document:

   "... the core model needs to specify that the signer MUST provide the
   assessor with a single, opaque value that the signer wishes to have used
   for assessment.  This value MUST be the basis for DKIM-based assessment.
   The signer MAY provide the assessor with a second, opaque value that MAY
   be used when reporting problems with the end-to-end DKIM process and MAY
   be used for additional analysis, such as by the higher-level Handling
   Filter.  These values are opaque, in that any internal semantics are
   known only to the signer and MUST NOT be assumed by the Assessor, within
   the confines of DKIM's formal signing specification.  Assessment MUST
   use a value as a single, complete and uninterpreted string."

"d=" is opaque?  And an assessor is not permitted to note that 
foo.spammer.org is a subdomain of spammer.org, the latter having a 
horrible reputation, and act accordingly?  The later discussion in this 
section describes what is meant by "opaque" but it doesn't seem to me the 
content of "d=" fits that description.

Does this language disallow evaluations of, say, the contents of "h=" or 
"l=" or "x="?

Nits in this section:

- change "an Web cookie" to "a Web cookie"

- change "that semantics" to "those semantics"

2.3. Choosing the Signing Domain Name

- change "their mail" to "its mail"

2.4. Recipient-based Assessments

- change "possibly by different of these actors" to "possibly by a number 
of these actors"

- change "industry practises establish" to "industry practises will 
establish"

- why is the "Absent such norms..." paragraph indented?

- an example of integrity vs. validity might be useful here, such as a 
sample of a signed spam or phish message

- suggest adding a subsection to discuss what I punted earlier, maybe 
something like this to get started:

   2.4.1 Local Reputation Data

   Using the identifier(s) discussed above, most notably "d=" and "i=",
   the Assessor may benefit from observing over time patterns in message
   validation, and/or correlation between those values and recipient
   reaction to associated content.  For example, if there is a high
   percentage of user complaints regarding signed mail with a "d=" value
   of "widgetco.example.net", the Assessor might include that fact in the
   vector of data it provides to the Handling Filter.  This is also
   discussed briefly in Section 5.4.

2.5 Filtering

- change "The discussion focuses on... Message Risk.  That is, the 
degree..." to "The discussion focues on... Message Risk; that is, the 
degree..."

- change "Only 3" to "Only three"

- what's "ORG TRUST M"?  should that say "ORG TRUST MODEL"?

3. DKIM Key Generation, Storage, and Management

- is the full RFC4871 citation necessary there?

Is the inference "That use of a specific key is restricted to a particular 
subset of messages" correct?  I don't know that it is, unless "subset" 
here includes the possibility of "entire set".  Plenty of sites have been 
using one key since installing DKIM for all mail.

- I believe the paragraph starting "The ability to draw any useful 
conclusion from..." is redundant to the ones above it.

3.1. Private Key Management: Deployment and Ongoing Operations

- "key-holder" is hyphenated in some places and not in others

- in "...refreshed at regular intervals, particular where key 
management...", change "particular" to "particularly" or "in particular"

- are there any external references to safe key management that could be 
made here, such as other RFCs, OpenSSL documentation, or printed material?

3.2. Storing Public Keys: DNS Server Software Considerations

- in "DNS record management is usually operated by..." I suggest changing 
"usually" to "often"; I've yet to work in such an organization, but I know 
they exist

- in "... is not a one time event, DNS DKIM selectors...", change the 
comma to a semicolon

3.3. Per User Signing Key Management Issues

- change "DKIM-base" to "[RFC4871]" or "the base DKIM specification"

3.4. Third Party Signer Key Management and Selector Administration

- change "In some applications, such as bulk mail delivery it is 
desirable..." to "In some applications, such as bulk mail delivery, it is 
desirable..."

The sentence "As with any other private key, ..." leaves me with the 
question "Why?"

- in "The domain holder minimizes their security risk", change "their" to 
"its"

- in "... a domain holder maintains full control over the creation of key 
records and employ appropriate key ...", change "employ" to "employs"

- in "The domain holder SHOULD not allow a ... access to their DNS 
service ...", change "their" to "its"

3.5.2. Example Key Termination Process

Is it prudent to discuss the empty "p=" in a key, versus outright deletion 
of the key?

4. Signing

- remove the comma in the first sentence

- change "there needs to be the appropriate means" to "there must exist 
the appropriate means"

4.1. DNS Records

- remove the comma before "for finding the specific public key"

4.2. Signing Module

- "outbound boundary MTAs to the open Internet" seems redundant to me; how 
about just "outbound boundary MTAs"?

- "One perspective that helps to resolve this choice is the difference 
between the increased flexibility..." reads awkwardly to me; suggest "One 
approach that helps to resolve this choice is to consider the difference 
between the increased flexibility..."

4.3. Signing Policies and Practices

- change "(message stream)" to "(i.e., its message stream)"

- aren't all of the points of this section already made in earlier 
sections?

5.3. Design Scope of Use

- add a comma between "assurance" and "bordering"

- in "private key holder may have lost control of their private key", 
change "their" to "its"

- in "high assurance public Key Infrastructure", capitalize "public"

Are we making a claim here that DNS spoofing, which could result in false 
positives, is not really a consideration during DKIM deployments?  That's 
how I read (part of) the lower half of this section.

5.6. Generation, Transmission and Use of Results Headers

- might be helpful to refer to draft-kucherawy-sender-auth-header since it 
also covers the issue of trusting the results as relayed from a verifier 
to something downstream; RFC number will be available shortly (just 
waiting for some IANA action)

6.1. Single Domain Signature

- the forward reference to ADSP might be problematic if it doesn't get 
published soon

- the sentence starting "Although an author signature might ..." reads 
funny; perhaps: "Although an author signature might in some cases be proof 
against spoofing the domain name of the RFC5322 From address, ..."?

6.3. Third Party Signature

- "third party" is sometimes hyphenated, sometimes not

- in "Parent Domain.  As discussed ... may also considered to be using 
...", change "also considered" to "also be considered"

- change "3rd" to "third" (multiple instances)

- change "to apply to only its own" to "to apply only to its own"

- change "The default is that a parent domain signature is considered 
valid..." to "The default is to consider a parent domain signature 
valid..."

6.4. Using Trusted 3rd Party Senders

- use "Third", not "3rd" (multiple instances)

- do identities sign?  I thought an identity was a property of an 
"entity", "agent" or "actor" (using our various adopted parlances).  I 
think the first paragraph of this section needs to be adjusted 
accordingly

- moreover, "identity" (or "entity", "actor" or "agent") are all singular, 
so use "its" instead of "their" as well

- in "For example, if Company A ..., they can use", change "they" to "it"

- in "A more reliable way of distinguishing the third part mail stream 
...", change "part" to "party"

6.4.1. DNS Delegation

- this is already discussed in section 3.4; perhaps that should contain a 
reference to Section 6.4. as a "for further information", otherwise this 
seems redundant

6.5. Multiple Signatures

- change "a single source" to "single sources", unless the intent is to 
infer one single machine handles all mail for lots of domains

- change "... no matter whether they represent" to "... no matter whether 
it represents"

- change "amoung" to "among"

- change "using either option two or three", to "the second or third of 
these"; alternately, do an enumerated bullet list so those cardinal 
numbers actually refer to something

- change "before that approach becomes pervasive" to "before one approach 
becomes pervasive"

- in "Companies with multiple subdomain identities:  A company that has 
ultiple subdomain sending ...", change "subdomain" to "subdomains"

- in "For example, Company A may sign mail for its sales department with a 
signature where d=marketing.companya.example, and a second signature where 
d=companya.example", why is sales mail signed with a marketing key?

- in "Service Providers:  Service providers may ... with either their own 
identity ...", change "Service providers" to "A service provider", and 
"their" to "its" (multiple instances); then "However, they" becomes 
"However, it", and "The existence of the service provider signature could, 
for example, help cover a new client while they establish their own 
reputation" becomes "The existence of the service provider signature 
could, for example, help cover a new client while it establishes its own 
reputation"

- recommend quoting or hyphenating "forward article to a friend"

- change "add their own signature" to "add their own signatures", and 
"vouch for it" to "vouch for them"

7. Example Usage Scenarios

- in "under the same reputation or different, and so on", change 
"different" to "a different one"

7.4. Author Domain Signing Practices

Are we holding this document until ADSP is published?  If not, that's a 
little strange; if so, a lot of this definition stuff is copied text that 
could perhaps be included by reference instead of by copy.

7.4.1. Introduction

The first paragraph is quite redundant by now.  Recommend dropping it, and 
changing the first sentence of the second paragraph to: "The legacy of the 
Internet is such that not all messages will be DKIM-signed, and ..."

- change "legitimate mail for that brand is signed" to "legitimate mail 
for a brand is signed"

- change "recipients can by more aggressive" to "recipients can be more 
aggressive"

- change "Sending domains that do not ... percentage of that mail" to "An 
actor that does not have complete control of all legitimate 
outbound mail purporting to be from its domains (i.e. with a From 
address in one of its domains) is likely to experience delivery problems 
with some percentage of its mail."

7.4.2. A Few Definitions

- "Valid Signature" (note capitalization) is used without defining it; 
recommend de-capitalizing it

- capitalization of "Local-part" requires that it also be defined first

7.4.3. Some ADSP Examples

- "... it is important to make sure you understand the nuances ..." is the 
first use of active voice in this document; recommend changing it to "... 
it is important to make the nuances are understood ..."

- similarly in the next paragraph, change "your" to "the"

7.5. Delegated Signing

- change "or they can delegate" to "or it can delegate"

- "Note that the From: address is not constrained: it could either be 
affiliated with the benefits company (...)" is an incomplete sentence

7.6. Independent Third Party Service Providers

- it looks like a "hanging" list in XML was used, where a regular bullet 
list would probably be preferable format-wise

7.7. Mail Streams Based on Behavioral Assessment

- change "their users" to "its users"

- change "distinct from the users email address local part" to "distinct 
from the local-part of the user's email address"

- in "the same user might have multiple i= values over the lifetime of 
their account", change "their" to "its" (or "his/her")

8.1. Non-standard Submission and Delivery Scenarios

Is it normal/safe/wise to use the specific examples of gmail.com and 
yahoo.com (which exist), or should contrived examples be used?

8.3. Signature Granularity

- in "The primary way to sign with per-user keys require that ...", change 
"require" to "requires"

- in "It is technically possible, to publish per-user keys within a ...", 
drop the comma

- I'm pretty sure "Identity Assessor" has not been used before this point; 
recommend just changing it to "Assessor" or "Handling Filter" (which have 
been used)

- again with the unusual use of a hanging list

- second-last paragraph gives another example of a concept that has 
already been quite thoroughly discussed elsewhere in the document

8.4. Email Infrastructure Agents

A crack at some permanent "anchor48" text:

   MUAs equipped with the ability to sign SHOULD NOT be encouraged.
   In terms of security, MUAs are generally not under the direct control
   of those in responsible roles within an organization and are thus
   more vulnerable to attack and compromise, which would expose private
   signing keys to intruders and thus jeopardize the integrity and
   reputation of the organization.

- in "it needs to make sure that it email infrastructure components", 
change the second "it" to "its"

8.5. Mail User Agent

"In particular, MUAs MAY also support DKIM signing and verifying 
directly."  This is true, but the former is a pretty bad idea (see above). 
Same with the "Outbound" paragraphs.

After "An MUA that looks ... trustable.", I would encourage reference to 
the Security Considerations of draft-kucherawy-sender-auth-header 
(publication soon) since its discussion is somewhat extensive.  The 
general concept of the paragraph "If verification ..." is also discussed 
in that draft.

A.1. Signers

- in "A signer that currently signs with DomainKeys (DK) will go through 
various stages as they migrate to ...", change "they migrate" to "it 
migrates"

- in the enumerated list, move the "and" from the first word of "2" to the 
last word of "1"

- should "Key Records" be capitalized?  I don't think it was formally 
defined anywhere above

- Replace "Note that when you have separate key records for DK and DKIM, 
you can use the same public key for both." with "Note that when separate 
key records are used for DK and DKIM, it is possible to use the same 
public key for both."  But while I'm thinking about it, is that really 
true?  Perhaps the intent has been lost and this should be rewritten 
anyway.

A.1.1. DNS Selector Key Records

- in "the g fields", recommend quoting "g"

- another strange-looking use of the XML hanging list; recommend 
reformatting

- is normative language allowed in appendices?

A.1.2. Removing DomainKeys Signatures

- change "until you decide it can go away" to "until it is deemed no 
longer useful"

- change "so you don't want to be signing with both algorithms for too 
long a period" to "so signing with both algorithms should not be 
needlessly prolonged"

- change "which ones of them do you care about" to "which of those are 
important"

- change "so you can find out" to "so it can be determined"

- in "discount those from your counts of DK selector usage", delete "your"

- change "consider stopping your DK signing" to "consider discontinuing 
signing with DK"

A.2. Verifiers

- change "you are faced with several issues" to "several issues must be 
considered"

- change "Do you verify DK signatures?" to "Should DK signature 
verification be performed?" (section heading)

- change "Do you verify both DK and DKIM signatures within a single 
message?" to "Should both DK and DKIM be evaluated on a single message?" 
(section heading)

A.2.3. DNS Selector Key Records

Isn't this materially the same as A.1.1?

Appendix B. General Coding Criteria for Cryptographic Applications

Is there an external reference that can be made, or should this work be 
moved to its own document?

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

---

From: Tony Hansen <[email-masked]>
Date: Sun, 19 Apr 2009 23:17:59 -0400

I want to thank Murray for his thorough review of the DKIM Design,
Deployment and Operations doc.

Anyone else want to join in on the fun?

	Tony Hansen
	[email-masked]