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(_dot_)net
ietfdbh(_at_)comcast(_dot_)net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf