Stephen,
Thanks very much for your careful review. I am incorporating most of
these; responses below.
Stephen Farrell wrote:
These are almost all editorial, a few content nits too though,
but no show stoppers at all.
Stephen.
------------------------------------------------------------------------
#1. Intro, para1: "..by querying the signer's domain directly..." makes it
sound
a bit like the verifier gets the public key from the signing MTA, maybe "..by
querying the signing domain's DNS entry..." instead?
Although use of DNS is the only key lookup mechanism currently defined,
DKIM does have the ability to specify a different mechanism, so your
wording strikes me as being a bit too specific.
#2. s1.1, after diagram says: "DKIM operates entirely on the content of the
message..." This could be a bit misleading since DKIM signs headers. The
problem is that someone might assume content=body and get the wrong end of the
stick. Suggest adding "(some headers and the body)" or equivalent.
OK.
#3. s1.1, diagram. Showing the queries with "...>" gives a sort-of wrong
impression, maybe better would be "<-->".
OK.
#4. s1.1, para after diagram, "alleged author's" seems wrong, would "alleged
signer's" be better?
No; Sender Signing Policy is always based on the alleged author's
address (perhaps better worded as alleged originator's address). Since
it's telling something about the policies of the originating domain in
the absence of a valid signature, there isn't an alleged signer.
#5. s1.2, 1st para suggest rewording to:
The remainder of this document describes the problems that DKIM might be
expected to address, and the extent to which it may be successful in so
doing.
These are described in terms of the potential bad actors, their capabilities
and location in the network, and in terms of the bad acts that they might
wish
to commit.
OK; I like your wording better.
#6. s3.2, 2nd para, s/hypothesized/demonstrated/ (or am I wrong?)
I don't know; I sent out a message on the Anti-Phishing Working Group
mailing list to see if anyone has seen actual attacks of this sort. In
any case, I'm fairly sure that such an attack involving DKIM hasn't yet
been demonstrated.
#7. s3.2.3 last sentence s/must be/should benefit from being/ The "must"
seems a
bit strong.
I don't want to soften the statement too much; I have already done so by
saying that the identity has to be "fairly reliable". Is this another
of those places where I slipped out of character and started to sound
normative? I could instead say something like, "reputation systems are
dependent upon the use of an identity that is, in practice, fairly
reliable." Is that version better?
#8. Typo in 4.1.3, end of para 1: s/observable/the observable/
OK.
#9. 4.1.3 suggest a tweak: s/the private key/the private key or some other
sensitve item/ There could be side-channel attacks where the attacker ends up
not getting the private key but getting some signatures (maybe even many) that
he could use.
OK.
#10. 4.1.4, I don't see the need to capitalise Chosen Message Replay. If
you do define the acronym (CMR) then you should use it (suggest not
defining it - its only used once). Same for 4.1.5/SMR.
The acronyms CMR and SMR are actually used more than once in 4.1.5 where
I compare the two attacks, but I could spell it out without much trouble.
#11 It might make sense to swap the order of 4.1.5 and 4.1.4 since 4.1.5
is more likely. If doing this then there's some text in 4.1.4 that could be
moved into the signed message replay section (3rd-5th paras). If not, then
maybe point back to those paragraphs frm 4.1.5, e.g. "The discussion of
potential countermeasures against replay from 4.1.4 applies here also."
I'd rather not swap the order, partly to minimize confusion on section
numbers, and also because threats are not described in likelihood (or
impact) order, and I'd prefer not to try.
#12 4.1.9, last sentence says "Recipients need to...". I think that that
should be "Verifiers need to...", since most MUAs won't know about
DKIM, right? Or maybe just delete the sentence.
MTAs that are verifiers may trim unsigned content from the message, but
we have also thought that MUAs of the future might distinctively display
unsigned content. How about "Verifiers and/or receiving MUAs need to..."?
#13, 4,1,14, s/time required/effort required/ since time-memory trade-offs
are common here
OK
#14, 4.1.15, 1st para s/which some/while some/ (not sure) and
s/an From/a From/
OK
#15, 4.1.16, s/(i.e., within a firewall)/(e.g. received from a firewall)/
I really meant, "that is to say, within a firewall" since they're
virtually ubiquitous in the kind of network I'm describing where the
originator's network has topological boundaries. I probably wouldn't
say "received from a firewall" since few of them are proxies or MTAs
themselves.
#16, 4.2.2, 1st sentence s/present/presents/
It needs to be "Internationalized domain names present" (as it says at
present :-) ) or "The use of internationalized domain names presents".
Which do you prefer?
#17, 4,3, 1st para, text is centred, rather than left justified.
OK.
#18, 4.3.1, 1st sentence: passive voice! Suggest rephrasing to
"Recently, an increase in..."
OK.
Thanks!
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html