ietf-dkim
[Top] [All Lists]

[ietf-dkim] New Issue: bunch of nits on threats-01 document

2006-03-09 08:03:39

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?

#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.

#3. s1.1, diagram. Showing the queries with "...>" gives a sort-of wrong
impression, maybe better would be "<-->".

#4. s1.1, para after diagram, "alleged author's" seems wrong, would "alleged
signer's" be better?

#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.

#6. s3.2, 2nd para, s/hypothesized/demonstrated/ (or am I wrong?)

#7. s3.2.3 last sentence s/must be/should benefit from being/ The "must" seems a
bit strong.

#8. Typo in 4.1.3, end of para 1: s/observable/the observable/

#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. 

#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.

#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."

#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.

#13, 4,1,14, s/time required/effort required/ since time-memory trade-offs
are common here

#14, 4.1.15, 1st para s/which some/while some/ (not sure) and 
s/an From/a From/

#15, 4.1.16, s/(i.e., within a firewall)/(e.g. received from a firewall)/

#16, 4.2.2, 1st sentence s/present/presents/

#17, 4,3, 1st para, text is centred, rather than left justified.

#18, 4.3.1, 1st sentence: passive voice! Suggest rephrasing to
"Recently, an increase in..."

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] Current Thread [Next in Thread>