Stephen Farrell wrote:
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.
Thanks, Stephen. I'll be able to get some of the simpler ones in for
-01; some of the larger ones will take longer and probably need a bit
more thought and discussion. Specifics on some of them embedded below:
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.
As we discussed, this restructuring is something that we should
undertake in the working group as it's a little too aggressive to do
before the Vancouver deadline. It's also answering a somewhat different
question than we had set out to answer.
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.
As we discussed, we'll need to import some of the discussion from the
-base and -ssp drafts, and then add to that as well. I would never be
so bold as to describe anything we write as "complete" though. We'll
also need to discuss what's a protocol issue and what's not: using your
timing analysis example, it's not clear that is a consequence of the
protocol so much as a potentially flawed implementation. But to use an
extreme example, presumably the threat of bribery of a system
administrator who has access to the private key is out of scope.
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.
I have written a little more about that. The logic is really more like
"trust relationships do exist internally => there are easier mechanisms
that could and likely would be used to foil bad actors".
4. Section 5 would be better if peppered with examples.
Sure; let's add those when we restructure.
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.
No, it doesn't; nor does it cover cases where the mail is signed by a
"lookalike" domain, e.g., bakofamerica.com or the famous examples using
internationalized domain names.
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.
Good point; not sure if I'll get this rewording in for the -01 or not.
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.
In practice, the modifications made by mailing lists do not lend
themselves to being canonicalized out. And since some mailing lists are
advertising-supported, if you had a magic canonicalization that ignored
the ads, an attacker could insert an "ad" for their client du jour.
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.
Sometimes you can, that's true. Large domains have an advantage here,
because they have more traffic to observe. Small domains are in a tough
position, because it's unlikely that they'll see many of anything and
the (mostly uncacheable) transaction load of looking up signature values
on a shared reputation system is likely to be very large.
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.
I'm not sure why this would more of an issue here than revoking a
domain's ability to receive mail by fiddling with their MX records.
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.
There was an earlier comment that we should be consistent with the other
drafts, so I'm planning to use the beginning of the -base-01 draft
introduction. The wording is somewhat more directly applicable.
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).
Section 3 wasn't intending to separate threats to DKIM from the pre-DKIM
threat environment. I didn't understand that this was an important
distinction in the revised structure either.
3. Section 3.2, last para - DNS poisoning doesn't really create a mitm between
sender and recipient, but between recipient and infrastructure.
That's true if you're poisoning the key. If you're poisoning the
recipient's MX record, it allows the attacker to establish themselves as
mitm the sender and recipient, which is what I'm referring to here.
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:-)
I'm not one of the aforementioned poor creatures, so I'll let others
suggest wording, if any.
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.
Added.
6. Section 4.1 is again talking about signatures in the last para.
Again, I don't see this as a problem.
7. Section 4.3, 1st para, s/happen/exist/
Thanks.
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/.
Thanks.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org
