Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Security review: draft-ietf-dkim-ssp-requirements-04 discusses requirements for the DKIM signing practices protocol. I felt the discussion of security issues for DKIM signing was very light. The Security Considerations section was also too light. My advice to the security area directors is that, before publication, this draft should document stronger security requirements for the DKIM signing protocol. This document should include an enumeration of the potential threats, as described in BCP 72 (RFC3552), followed by a discussion of the requirements that must be met by DKIM signing to mitigate those threats. - a few specific comments related to security issues: 1) section 5.1 discusses discovery requirements. bullet#1 says the author is the first party sender of a message. After reading this, I had the question "author of what?" The preceding text only says there must be a means of obtaining information. It doesn't discuss any particular approach to getting the information, so I am not sure what is being authored. 2) section 5.1, bullet #4 says the WG might not be able to reach a consensus on a solution that completes within a deterministic number of steps, and if they do not reach consensus, then they MUST document the relevant security considerations. Even if they DO reach consensus, they will need to document the security considerations. I'm not sure how they will document the security considerations of not reaching consensus. I think there are range of topics mixed into bullet#4, and they need to be broken out before security for these things can be considered. 3) section 5.3 bullet #2 calls for a concise linkage between the identity in the From field and the DKIM i= tag. Isn't the concise linkage that you need here some type of identity authentication? If not, how do you know the mapping is actually valid? 4) security requirement#1 - What must SSP do to prevent such DoS attacks? what must SSP do to prevent being vulnerable to such DoS attacks? Note that these are two separate questions with potentially different mitigation strategies. 5) security requirement#2 - what must SSP do to prevent such attacks? Keeping exchanges small might help, but how about establishing a secure channel, and using data origin authentication, and message integrity checking, and replay prevention, to prevent such man in the middle attacks? 6) there is mention of DNS providing cacheing. I have some concerns that this may not be appropriate for DNS applicability, and there could be security concerns introduced if DNS is used to provide cacheing for this protocol. - Other comments: 1) I found the 1st paragraph of section 4 unparseable. I recommend using multiple sentences here, rather than one long run-on sentence. 2) s/(ie,/(i.e.,/g 3) This document should have **requirements**, and the informative notes feel wishy-washy. Many requirements are not definitive requirements, so it will be hard to tell whether the protocol actually meets the requirements. Some of the informative notes gave a much better description of what is expected, and I think the non-informative-note-text would benefit from being described more fully, and eliminating the informative notes. 4) I think some MUST/SHOULD language is not being used as per RFC2119, and should be tightened. There is also use of lowercase "must" and "should"; is this meant to also be consistent with RFC2119 usage? If not, the "requirements language" section should explain this. 5) section 5.2 bullet#3 says "If the infrastructure doesn't provide caching (ala DNS), the records retrieved MUST provide initiators the ability maintain their own cache." I don't understand how retrieved records can provide this ability to initiators. Either the protocol needs to provide a caching mechanism (possibly ala DNS), or implementations do. 6) There are a number of sentences in this document that do not follow the rules of English grammar. For example, in the 1st paragraph of section 5.3, there is no subject-verb formualtion, only a couple of cluases strung together. The grammar makes it hard to read this document without being forced to go over sentences multiple times to understand the intent. 7) "intuitive" is in the mind of the beholder. I think it is debatable whether p=? is less intuitive than p=unknown. What is needed is a clear and unambiguous syntax about what p=? or p=unknown means. 8) section 5.4 bullet#1 sounds like something to write in the charter, not the protocol requiremnets document. 9) section 5.4 bullet#2 - are there already existing discovery/transport/practices to be backwards compatible with? Or is this saying the future extensions to the future protocol must be backwards compatible with the future protocol? David Harrington dbharrington@xxxxxxxxxxx ietfdbh@xxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf