Below are some comments on dkim-overview-05. I'll start out with some general comments and then go through section by section. I'll try to avoid grammatical nits at this point, although sometimes I just can't help myself.
General: The document seems to be inconsistent as to whether it's just being descriptive of DKIM and its environment or whether it's a normative document. The language used seems to be all over the place between descriptive, "the verifier obtains the domain name from the DKIM header field," non-normative "should" and normative "SHOULD." There's some inconsistency as to whether SSP is included in this overview, and where it is, it makes some assumptions about SSP that haven't been decided yet. There is little guidance about the use of multiple signatures in a message. In particular, an invalid signature shouldn't cause the message to be treated as unsigned: there could be other valid signatures. Top-level structure of the document needs serious work. There are a lot of subsections that don't fit within the section they're in. The introductory material seems to go on forever. The background on the email administrative structure should be limited to the minimum that is needed to set the foundation for the rest of the document. Specifics: 1.1 paragraph 1: Use present, not future, tense. 1.1.1 paragraph 3 s/An attack is made/Suppose an attack is made/ "leverage" implies amplification: need a better word. s/DKIM-based accreditation/domain-based accreditation/ (and please define accreditation somewhere). s/enforce a basic separation/differentiate/ 1.1.1 paragraph 4 s/It can also/They can also/ Example of "independent service"? s/the basis/a basis/ 1.1.1 paragraph 5 s/not signed by email/not signed by DKIM/ Should SSP be mentioned, since it affects how unsigned mail might be handled? 1.1.2 paragraph 1 s/therefore trusted to be accurate/therefore assumed to be accurate/ 1.1.2 paragraph 5 s/semantic implication of the assertion/semantic assertion/ 1.1.2 paragraph 6 don't understand what is meant by "technical aspect" 1.1.3.1 Under ADMD Examples, why is an ISP an ADMD, unless it is also a Mail Service Provider? 1.1.4 paragraph 2 delete 1.2 I thought 1.1.1 was all about the goals of DKIM? 1.2.1 Do we want to make any comparisons with SPF or SenderID, even though they are Experimental? In particular, they also work at the domain level. 1.2.1 paragraph 2 s/sign with any domain name/sign with any domain name for which they have authority/ s/DKIM needs to support/DKIM supports/ This paragraph in particular sounds like a list of requirements (or deficiencies) for DKIM, rather than what it does, e.g., "DKIM must support this mode of activity" s/not visible/not typically visible/ 1.2.1 paragraph 3 Ability to send a message without signing is also a factor in providing anonymity. s/does not threaten the anonymity of the user/may not threaten the anonymity/ (a signature from my personal domain would definitely threaten my anonymity!) 1.2.2 paragraph 2 Need to reword in terms of invalid signatures being ignored, not treating the message as a whole as (necessarily) unsigned. The treatment of failed signatures as not present does not derive from transparency, but rather from the following consideration: Message signatures MAY break in transit, so treating a message with a broken signature any worse than an unsigned message would tend to discourage signing. 1.2.2 paragraph 4 Delete "accreditation" since that is done on behalf of the sender, and this is talking about a list maintained by the receiver. 1.3 SSP should be referenced here. 1.3.1 Don't understand first sentence; perhaps s/associates a domain name with an address/chooses a sending identity/ 1.3.1 paragraph 3: Does this belong in 1.3.3? The service restriction isn't nearly as interesting as the key record's restriction of signing algorithms and perhaps the user-part of the signing address. 1.3.3 first sentence: A signature really associated with a signing address, specified in the i= tag, although the entity doing the signing usually does so for all addresses in the domain. d= is really the place to look for the key, and may be the same as or sometimes a parent of the domain-part of i=. 1.3.3 paragraph 4: I have some trouble with the "should use different sub-domains" (assuming it's trying to be normative). This is, in effect, recommending changes in the way organizations address their email, which I thought we were trying to avoid. It's also not clear to me whether reputation services will key off d= or i=; using i= probably makes it easier to make up subdomain names in order to avoid negative reputation, but it's fairly easy with d= as well (just requires more key records). 1.4: Figure 4 doesn't address multiple signatures. 1.4 paragraph 3: s/Unsigned messages/Messages lacking a valid signature corresponding to the <2822.From> address/ 1.4 paragraph 4: "are treated": is this normative? 2.1.1 There isn't much that's unique about DKIM in terms of crypto coding considerations. Isn't there something we can reference? In paragraph 4, why would timing attacks be limited to dual-core and multiprocessor configurations? 2.1.2 paragraph 4: Why would certificate registration make any difference at all? 2.1.2 Should there be any guidance on delegation of keys? Should there be a section 2.1.3 giving guidance to verifiers? 2.2 paragraph 2: To whom (the submitter or the email administrator) is the "operator alert" issued? I'm mixed about the utility of such alerts, because the vast majority of non-compliant non-signers will submit through a completely different path that doesn't do any checking. If this is normative, I'd make it a MAY. 2.3 paragraph 2: s/about the message/about the message or the signing domain/ s/a spammer or other malefactor/an attacker/ 2.3 paragraph 4: s/scheme/verifier/ s/reputation data/reputation data (including locally-maintained whitelists)/ 2.5.2.1 talks about what the verifier does, but it's under section 2.5.2 "Signing". 2.5.3.1 paragraph 2: How does the first sentence relate to SSP? 2.5.3.3 paragraph 2: advocate stripping only those Authentication-Results header fields that purport to be from the ADMD doing the stripping. Otherwise this may break DKIM signatures that sign Authentication-Results header fields as described under "intermediaries" in section 2.2. 2.5.5.1 talks about advertising the algorithms that are both being used dueing a transition period, but 2.5.5.2 does not reference that advertisement. Why is it required? 2.5.6.1 paragraph 2: s/principle/principal/ 2.5.6.1 doesn't talk about whether either signature signs the other. IMO the signatures should be independent, which means that the DKIM signature must precede the DK signature. 2.5.6.2. paragraph 2: what is there to see in the section on Signing? Are there any SSP issues to consider? 2.6 first bullet: s/files/records/ 2.6.1: First paragraph might also discuss the option of putting the _domainkey subdomain in a separate zone which is maintained directly by the email staff. Second paragraph s/WILL and// 2.6.1.1: bullet 3, what kind of "exposure" do you mean? 2.6.1.3: it was a goal (of IIM, anyway) not to require domains to change their addressing practices, such as this describes. Maybe we didn't achieve that, but the ability for an attacker using his/her own domain to create a new subdomain and get a fresh reputation brings the reputation-silo-via-subdomain issue into question. I thought we were considering ways of maintaining reputation as out-of-scope for the WG? In other words, I wouldn't expect that reputation providers will necessarily work this way. 2.6.1.4: This uses the term "third-party" in a different meaning than its use in SSP. We should resolve this. 2.6.3: Why is the section on Mailing list manager developers" under "On-going operations"? There should be some guidance on what signing address should be used by mailing lists: is it the sender, list-ID, etc.? [EMAIL PROTECTED], [EMAIL PROTECTED], or [EMAIL PROTECTED] 2.7.1: "...can be presumed to be spurious". Not so; messages could originate from the domain, be sent to a mailing list that breaks the signature, and back to the same or other users in the originating domain. 2.7.2.1: I don't understand what these are. Accreditations? Missing Security Considerations and IANA Considerations sections. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
