Hi Jim,
I reckon this is one issue we can close before the meeting:-)
#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.
Fair enough. How about "...by querying a the signer's domain (e.g. via
their DNS entry)"
#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.
OK. Sorry 'bout that.
#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.
OK.
#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?
Yes its fine IMO.
#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.
Happy with whatever you decide. (From working a little with some NASA
types, I sometimes get an alergic reaction to excessive acronym
creation - EAC:-)
#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.
Fair enough.
#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..."?
Fine by me.
#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.
I guess "within a firewall" is what struck me as odd - it sounds like it
means "within some Checkpoint s/w" (or Cisco I guess:-) How about
"from within a firewalled network" or something?
#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?
You choose. I obviously cannot read:-)
Stephen.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html