[ietf-dkim] comments on the threats draft
stephen.farrell at cs.tcd.ie
Wed Oct 19 05:46:17 PDT 2005
Here are some comments on the threats draft which looks to me
like a very good start.
The main one is the stuff about the structure, most of the others
are much less of a deal, and that was already raised so there's
not too much new here.
If you've time to take some of these into account for -01 that'd
be great. If not, I can bring 'em back to the list later on.
-------------- next part --------------
1. Structure suggestion as per list discussion. The main problem which that
might address is that its quite hard to be confident that this document's
coverage is sufficient. BTW I don't expect that a -00 version would be
complete, so its not a criticism of content, just structure. There're also no
requirements here against which I can easily test the protocol specs. Lastly,
there's no information about the liklihood, nor much about potential impacts so
I can't see which threats should be prioritised.
2. There should be a complete analysis, including threats caused by/to the DKIM
protocol. There is in fact some text along these lines (see the nits below),
but we should include as much as we can here.
3. Is there any empirical data supporting the concentration on externally
located bad actors (as per 4.1)? If so, it'd be good to reference that. If
not, then what's the justification? I don't find the logic that "trust
relationships do exist internally => no problem with bad actors" argument
4. Section 5 would be better if peppered with examples.
5. Does section 5.2.2 cover cases like a mail from "support at ebay.example.com"
signed by example.com's MTA? If not it should be covered somehwere. If so,
maybe reword to make this clearer or else add an example which does so.
6. Section 6.2, 2nd last para says that reputation requires a reliable
identity, which isn't quite true if you're limiting identities to be names. I
could build a strong reputation system simply from the continued use of a
signing key which isn't really an identity according to many definitions.
7. Section 6.2, last para. Its not quite true that message modification
reqiures that intermediaries sign. In principle one could create a canonical
format which almost never got mangled and so avoid the intermediary signatures.
While that may be much less practical than what we're currently doing, it is
8. DKIM can help a bit with message replay in that it can allow for better
volume controls. Say if I keep a count of the number of times I see a given
set of signature bits in a time window and once the count crosses a threshold I
become more agressive in treating the message as spam. The point is that the
signature itself is a handy reply detection value so even if I can't detect
*a* replay, I can possibly detect excessive replay.
9. (Part of #2 above really but worth calling out) DKIM creates new
opportunities for service providers (key managers, DNS providers) to sort-of
revoke a domain's ability to send mail. Those should be discussed so we can
minimise them to the extent possible.
1. Introduction/abstract could maybe copy text from the latest charter, e.g.
current 1st para makes the talks about mechanism but charter now talks about
2. Section 3.1, 1st bullet list - item 3 does assume the DKIM protocol,
otherwise there's no key! Same applies to 3rd, 4th & 5th bullet of next list
(though those could be partly re-worded to be DKIM protocol independent).
3. Section 3.2, last para - DNS poisoning doesn't really create a mitm between
sender and recipient, but between recipient and infrastructure.
4. Section 4, 1st para. Is an admin. unit the same as an x.400 ADMD or PRMD? If
so, you might want to say that since I guess there are some readers who'd be
enlightened by that (the poor creatures:-)
5. Section 4, 2nd para. Bad actors can also collude, in particular on both
sides of a victim. In other words there can be distributed bad actors.
6. Section 4.1 is again talking about signatures in the last para.
7. Section 4.3, 1st para, s/happen/exist/
8. Section 4.3, 1st para - this assumes that DKIM verification is only doable
once. Why? Maybe better to say that it'll typically happen only at the
boundary, i.e. s/typically have/typically only have/.
More information about the ietf-dkim