Hi, Some comments after a review of the adopted document:
(1) I find the abstract is more readable if broken into three paragraphs, with the second starting "DKIM survives ..." and the third "This document discusses ...". (2) Throughout the document, the proper term "Replay Attack" (and sometimes "Replay") is used, but it's never directly defined. I don't think you need it to be formal, but if you really want to do it that way, please add a definition for it. (3) The first sentence/paragraph of Section 1 isn't necessary. (4) The last paragraph of Section 1 refers to the "DKIM domain" but I don't think this is defined anywhere. It's also not clear that if the signature doesn't validate, there is no output from DKIM in terms of an authenticated identifier. Maybe "DKIM-authenticated domain"? (5) In Section 1.1, "The presence of a validated DKIM signature" begins two sentences. I suggest some wordsmithing here. (6) In Section 1.1, the sentence ending "particularly for systems" reads funny. I suggest: "However, that attack has become commonplace, and typically manifests itself as follows:" (7) In Section 1.1, for the first bullet, suggest: "Attackers create, obtain access, or compromise an account at some Originator that signs messages with DKIM, preferably one that has developed a positive reputation;" (8) Second bullet: "Attackers locate a Receiver that consumes DKIM to make a delivery decision." (9) Third bullet: "Attackers send an email from that account to an external account also under their control." (10) Fifth bullet: "Attackers then post the message to a new and large set of additional recipients at the Receiver." (11) s/in the content/in the visible/ (12) De-bullet the "Further, a message used ..." paragraph. (13) Define the term "re-posting flows", or give an example. (14) Add "experimental" to the ARC reference. (15) In Section 1.2, strike the "NOTE". This is an Informational document so this isn't necessary (and this way you can drop the BCP 14 reference). (16) Also in Section 1.2, importing definitions from RFC 5598 verbatim is not necessary and risks editorial drift; simply making the reference and advising the reader to be familiar with it is sufficient. (17) Also in Section 1.2 at the end, two things: (a) Mentioning that DKIM is an authentication protocol used by the above described actors is, IMHO, redundant; and (b) on review of the document as a whole, I don't think mentioning SPF adds anything, so I suggest we consider removing it. (18) In Section 2.2, we refer to "author". If this should be "Author" as defined in RFC 5598, be sure to capitalize it. If we mean something else, what? (19) Also in Section 2.2 it talks about sending a different message. Different how? (20) Section 2.3 talks about an alias replacing the envelope sender. Is this true? I don't think, for instance, that sendmail replaces the envelope sender when it routes a message through an alias. (21) In Section 3.1, the first paragraph is effectively a restatement of Section 1.1. Can we drop it? (22) Also in Section 3.1, I suggest not mentioning "spam folder" as that's one of any number of possible handling choices. Maybe just talk about "misclassification"? (23) Also in Section 3.1, the last sentence seems to be redundant; I suggest removing it. (24) Sections 3.2 and 3.3 are too short to be their own sections, and end the same way. I suggest common factoring. (25) Section 4 says things like "SMTP Envelope RCPT-TO", but we already have a notation for this (RFC5321.RcptTo), which other specifications related to DKIM use. I suggest using those. (26) In Section 5.1, s/original sending/original message/ (27) Section 5.1, first bullet: "This prevents a valid signature from being replayed to destination addresses not anticipated by the DKIM signer" (28) Second bullet: s/ENVELOPE-TO/envelope recipients/, or use the notation mentioned above. (29) Section 5.2, "known DKIM signatures" needs a better definition; known how? Are we talking about the whole header field, or just the "b" value? (30) Section 5.4, I remember mentioning at M3AAWG that RFC 6376 recommends against using "x=" for replay mitigation. I also think there's been evidence presented (I forget where) that enforcement of "x=" is not universal, so it's not a reliable mitigation. We should mention these. (31) In Section 5.5, s/spec/protocol/ (two instances) (32) Suggest replacing Section 6 with: "Readers interested in this problem space should already be familiar with the Security Considerations described in [RFC6376]. The problem described in this document amounts to a privilege escalation attack against email content filters. Mitigation or solution documents may follow." -MSK, just participating
_______________________________________________ Ietf-dkim mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf-dkim
