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