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

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Mar 2006 14:49:22 +0000

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 13 Mar 2006 17:23:20 -0800

Stephen,

Thanks very much for your careful review.  I am incorporating most of
these; responses below.

Stephen Farrell wrote:
> ------------------------------------------------------------------------
>
>
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.
> stick. Suggest adding "(some headers and the body)" or equivalent.
OK.
> impression, maybe better would be "<-->".
OK.
> #4. s1.1, para after diagram, "alleged author's" seems wrong, would "alleged
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.
>  and location in the network, and in terms of the bad acts that they might wish
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
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.

> not getting the private key but getting some signatures (maybe even many) that
OK.
> 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.
> 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.
> 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
OK
> #14, 4.1.15, 1st para s/which some/while some/ (not sure) and 
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.
> "Recently, an increase in..."
OK.

Thanks!

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2006 17:48:38 +0000

Hi Jim,

I reckon this is one issue we can close before the meeting:-)

> 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)"

> the absence of a valid signature, there isn't an alleged signer.

OK. Sorry 'bout that.

OK.

> reliable."  Is that version better?

Yes its fine IMO.

> 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:-)

> impact) order, and I'd prefer not to try.

Fair enough.

> unsigned content.  How about "Verifiers and/or receiving MUAs need to..."?

Fine by me.

> say "received from a firewall" since few of them are proxies or MTAs

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?

> present :-) ) or "The use of internationalized domain names presents". 

You choose. I obviously cannot read:-)

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 14 Mar 2006 11:02:21 -0800

On Mar 13, 2006, at 5:23 PM, Jim Fenton wrote:

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

This aspect of identification becomes the basis for the disagreement  
with respect to the impact on message replay abuse.  Accruing fair  
reputations indeed needs "fairly reliable" identifiers.  In the case  
of a signature, the nature of the abuse must also be limited to the  
signed portion of the message.

This limitation creates a significant dilemma not considered in the  
threat review.  Both the frequency and the recipient of the message  
must be excluded from a reputation assessment which emasculates any  
DoS protections the reputation history should provide.  When the  
reputation accrual unfairly includes the envelope to restore DoS  
protections, then the impact resulting from abusive message replay  
affects the domain as a whole and should be deemed a high impact.

There is a solution that exists outside of DKIM, but must be mandated  
in conjunction with DKIM, or recipients remain highly prone to DKIM  
DoS attack.

-Doug