[ietf-dkim] [Fwd: secdir review of draft-ietf-dkim-ssp-requirements-04]

[Hector Santos]

Eliot,

Thanks for the FYI. It reaffirms what my own assessment of the SSP 
requirements document.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


Eliot Lear wrote:
> FYI
> 
> ------------------------------------------------------------------------
> 
> Subject:
> secdir review of draft-ietf-dkim-ssp-requirements-04
> From:
> "David Harrington" <ietfdbh at comcast.net>
> Date:
> Mon, 16 Jul 2007 17:27:41 -0400
> To:
> <dkim-chairs at ietf.org>, <secdir at mit.edu>, "'Sam Hartman'" 
> <hartmans-ietf at mit.edu>, <tim.polk at nist.gov>
> 
> To:
> <dkim-chairs at ietf.org>, <secdir at mit.edu>, "'Sam Hartman'" 
> <hartmans-ietf at mit.edu>, <tim.polk at nist.gov>
> CC:
> "'Michael Thomas'" <mat at cisco.com>, "'IETF discussion list'" <ietf at ietf.org>
> 
> 
> 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 at comcast.net
> ietfdbh at comcast.net
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf at ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html