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

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
        tony(_at_)att(_dot_)com

Murray S. Kucherawy wrote:
> 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
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html