Hi Jim,
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. Regards, Stephen.
Bigish things:- 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 sufficient. 4. Section 5 would be better if peppered with examples. 5. Does section 5.2.2 cover cases like a mail from "[EMAIL PROTECTED]" 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 possible. 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. Nits:- 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 service. 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/.
_______________________________________________ ietf-dkim mailing list http://dkim.org
