Jim, All,
Here's a few comments on -02 of the threats document, which seems
to me to represent really good progress,
Cheers,
Stephen.
Note1: these are offered strictly for consideration and not
wearing any wg-chair type hat - but I hope they aren't controversial
in any case (or at least no more controversial than any mail to
this list;-)
Note2: there's no need to respond to these blow-by-blow, just
take 'em into account, or not, as you're doing edits on the next
version. Though I guess the 1st set are more perhaps likely to
become issues on an issues list.
Note3: some of these overlap with list discussion that's gone
on recently, in which case feel free to disregard me - I didn't
have a chance to compare this with all of the recent emails.
General/bigger:
===============
1. Forward references. The document references the base and ssp drafts. That'll
cause this to be held in the rfc editor's queue until those documents are done.
If possible, we might want to remove those dependencies somehow (e.g. reference
some paper about dkim/domainkeys instead and leave out ssp). Seems a bit silly
I admit, so I'm not sure. What I'd like is to avoid the temptation to re-do the
threats document after the IESG have ok'd it, since that could put us back to
step 1 if we're not careful/unlucky.
2. Definitions of impact & likelihood. (Currently in section 4, page 10). I'd
like to see a bit of discussion about these, although its not an easy thing to
capture correctly, and your current definitions are not at all bad.
Some points though:
a. "high impact = affects verificaton in 1 or more domains" doesn't seem to
properly capture access to the signing key if that were used only for e.g.
messages sent to one recipient/domain. I think that there should be something
about the degree of freedom available to the attacker.
b. "high likelihood = all users of DKIM", I'm not sure its correct to limit
things to only considering "users of DKIM", I think that the threat is likely
or not regardless of who's a DKIM user, though being e.g. a DKIM verifier will
sometimes reduce the impact, and once there are enough DKIM verifiers, then
perhaps that could reduce the likelihood.
Maybe it'd be a better approach to avoid attempting rigorous definitions and
just say that these are defined in whatever ad-hoc manner the wg chose, but
then to give some examples to make them clear.
3. Delegated keys. There are a range of serious threats here that can perhaps
be bundled, but which need consideration. In fact, I've got some real concerns
with the entire idea of delegated keys. Questions that arise include: who
generates the keys? If the domain-owner does and hands over the private key to
the delegate then how is the key protected during that exchange? If the
delegate generates how does it get the public key into the domain signer's DNS?
There's protocol needed either way and its not currently specified as far as I
can see. So I think either 4.1.2 needs a good bit of work or else if we can
agree to long-finger delegation then we could leave it for now (though I guess
that there are real requirements for this - not that I understand them though).
4. Completeness. I don't know how to do this, but I'd be very interested if
anyone has ideas about how we might convince ourselves (and eventually the
IESG) that the threats we've identified constitute a relatively complete list.
Middling things:
================
1. Section 4.1.1. There're a range of fairly cheap, standard crypto hardware
devices that can be used to dramatically decrease the likelihood of private key
theft. (Some have options so that a physical token or two is required to be
present for the device to operate.) I'd suggest adding a sentence that "The use
of hardware cryptographic support is probably the simplest way to effectively
protect MTA private keys." (Such crypto h/w might also be needed for
performance on a busy server.) However, the likelihood of some domain's private
key haven been stolen is IMO high, given the number of domains there are, and
that mant domains will use s/w and be relatively insecurely configured. So, I
think that it might be better to split this into two threats: the first is the
threat that any randomly selected domain's private key has been stolen which is
high-impact, low-likelihood. The second is the threat that some domain's
private key has been stolen, which is (arguably) medium-impact,
high-likelihood. I think DKIM can do a good job for the former, but perhaps not
for the latter where the best we can do is include security considerations
exhorting the implementer to protect the keys (this threat though does show up
the need for such sec. cons. text.)
2. I didn't see where the one-bit-gif threat we discussed in Vancouver fits.
This is where an attacker sends a signed message in order to check which
recipients are verifiers (by monitoring the public key/policy lookups). The
attacker then knows the non-DKIM recipients and can target those for additional
spam or whatever.
3. I don't know the answer here but is the following a kind of DoS? Could an
attacker add additional information to a DNS record s.t. the record is then
too big for UDP, forcing a failover to TCP which may not work. If this could
happen is there a field that's extendable that'd suit? (If this can happen
maybe adding a note to 4.1.11 would be right.)
4. The last sentence of section 4.1.14 is a good example of the kind of
derived security requirement that could go into section 5. I guess so long as
those kinds of statement are easy to find, then it doesn't matter if the text
is in section 5 or elsewhere. (They could be marked by indentation and
numbering or else by copying them to section 5.)
5. Section 4.1.4 is called chosen message replay which is an interesting name
and would remind one of chosen ciphertext attacks. In which case, is it
worthwhile considering known message replays? Where the attacker can predict,
(or prompt), but cannot choose, the content of the to-be-replayed message?
Actually, known message replay may be more dangerous, since the countermeasures
in 4.1.4 mightn't apply as well.
Nits & specific things:
=======================
0. The tone of the intro is still a little wrong. The draft should not be
selling dkim by claiming its "simple, low cost and effective". Having read to
the end now, this is an isolated case, but so early on it does give the wrong
impression - just changing that sentence should be enough.
1. Intro, para2: " By applying a signature, a good player will be able to
associate a positive reputation with the message..." Not really since its the
verifier that associates anything positive with the message. Suggest adding
that, i.e. "a good player enables a verifier to associate..."
2. There's a bit of a leap from the end of the intro to section 2. Suggest
adding a paragraph or two outlining the document structure. I mean something
starting with "This remainder of this document is structred as follows: ..."
and with a bullet for each section worth mentioning.
3. Section 2.2, 1st list, item 3: "...published by..." assumes a certain design
for ssp, maybe better say "...associated with..." for added-extra design
independence.
4. Section 2.2, 2nd list, item 1: Should this say something like "to MTAs
and/or MSAs" or the like? I guess it depends on what ends up in the terminology
appendix, but if we differentiate between those then both should get a mention
here I suppose.
5. Section 2.2, 2nd list, item 3: What does untraceable mean here? I guess I'm
nearly sure - I suppose it means where you can't get other information about
the domain, though they'll probably only sign if a verifier can at least get
the public key, which implies that you can find some stuff in DNS about the
domain. Perhaps better to just omit "untraceable".
6. The ssp draft is in the references, but is not actually referenced. I'd
guess that there might be one missing in the 1st para of section 4 (but see
general#1 above.)
7. If we're only using one term from I-D.crocker-email-arch, then it should be
easier to repeat the definition here rather than take on the draft dependency
involved (unless I-D.crocker-email-arch is just about ready to go to the rfc
editor and not controversial - I don't know anyway). Similar comment about
I-D.kucherawy-sender-auth-header, if its likely to delay RFCdom then maybe find
another way to say this.
8. Section 2.3, last para. Collusion doesn't require simultaneous action, it
could be sequential or even substantially delayed. Suggest changing to: "...by
acting from multiple locations (a "distributed...".
9. Section 3, intro para. "...not authorized by..." Is it useful to put things
that way when there's been so much mention of authorization on the list? Maybe
better to say "...not intended to have been delivered by the alleged
originating domain." Sounds a bit clunky though. (I guess it may also be good
to change this since there are many domains which don't do anything that they
would call authorization on good outbound email.)
10. Section 4, 1st para. "...often referred to..." is a bit much. I guess
"...referred to here..." is better.
11. I'd move the description of impact and likelihood from section 4 up to the
end of the intro (if you put in the document-structure point there).
12. Section 4.1.3 would be better called "Private key recovery via side-channel
attacks" since that'll cover timing, power and other various similar cases. The
text would the need modification to talk about "timing and other side-channel
attacks" of course. Specifically, I'm not sure that we want to say that an MTA
"has" enough variablility since some of these attacks can be very sophisticated
and based on timing many many messages. I'd say "probably has" instead.
13. Section 4.1.4, the last paragraph would appear to fit better in 4.1.5 or
does it? (No need to reply if the answer's "no":-) Secondly, the text mixes up
revocation of signatures and revocation of keys. The former suffers from the
scaling problem mentioned, the latter from the side-effect problem that lots of
customers may be affected. Suggest separating these into two separate
paragraphs, one on signature revocation one on key revocation.
14. Same topic. I'm not sure that there's any need for any separate message
revocation identifiers since the signatures are specific to the messages. If we
wanted to group messages for revocation purposes then we'd be forcing all
verifiers who care about revocation to use the same grouping. Now while that
could be done, I'm not sure there's sufficient benefit and it could in any case
probably be better done via some generic extensibility mechanism.
15. The make-work attack in 4.1.6 can only really be countered by maintaining
state in the verifier and noticing when too many messages are failing
validation and then ramping up other checks. (Maybe there're other ways, but I
bet they're the same in the end.) Absent some anti-DoS features in SMTP I think
that that's the best that can be done and maybe worth a mention.
16. Not sure but maybe worth noting in 4.1.7 that other (non-DNS) key servers
are likely to be much more vulnerable to DoS attacks based on simple overloads.
17. Is there a contradiction between 4.1.5 and 4.1.9? 4.1.5 says that mailiing
lists forwarding/exploding a signed message is a kind of signed message replay
and that the network cannot determine this (since the verifier has no way to
know what's a mailing list and what's not I assume). 4.1.9 says that we use
body-length-limits to allow mailiing lists that append trailers to forward
signed messages. So, which is it? I guess one or both statements need caveats
added.
18. 4.1.9 - is it worth mentioning that l=0 is unreasonable?
19. 4.1.10 - would this be better named "Use of expired keys" since it seems to
assume that key expiry is the only revocation scheme (which probably makes
sense).
20. 4.1.11 - at this stage of the game, the reader doesn't know what a key
selector might be. Maybe explain a bit or use an abstraction? (Very minor note
is that rather than deleting the real key, the attacker could also just corrupt
it and get a slightly different DoS effect.)
21. 2.3.2 and 4.1.16 seem to overlap a bit. Maybe that indicates that some more
restructuring is needed?
22. Section 4.2.3 could be written more abstractly - any policy scheme that
requires a lookup based on receipt of unsigned messages can be abused like this
so its not necessary to say that its the SSP record.
23. Section 4.2.4 s/is rare/has never been seen in the wild/ :-)
24. Section 3.1, 2nd para says that "DKIM is effective in mitigating
against..." Well, if the bad actor say takes down the DNS knowing the verifier
is configured to forward the mail if DNS fails, then DKIM would not be
effective. Secondly, if the address in question is controlled by someone who
doesn't actually sign anything then DKIM again isn't effective. So, I think
this should say that DKIM "can be effective" instead. (There are other similar
cases, e.g. maybe 3.2.1 2nd para s/would/could/.)
_______________________________________________
ietf-dkim mailing list
http://dkim.org