I'll probably answer in more detail than you need, but anyway...
Stephen Farrell wrote:
------------------------------------------------------------------------
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.
I'm going to minimize dependencies (defining terms locally rather than
referring to crocker-mail-arch, for example) but I don't know what to do
about the DKIM references themselves. I have called them "informative"
but I'm not sure that keeps us out of that hold queue, and perhaps I'm
just kidding myself about the "informative" part(?)
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.
I used the term "by" which I realize now is ambiguous. How about
"messages from and entire domain or multiple domains"?
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.
I mention DKIM users primarily because non-users are unlikely to notice
an attack on DKIM.
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).
The specs don't describe how the key delegation takes place, but of
course it's better if the delegate generates the keypair and gives the
public key to the domain owner. But then there are ways of doing the
delegation that don't involve any keys changing hands, using things like
the dotted selector mechanism (via NS records, the domain owner
delegates the foo._domainkey.example.com subdomain to delegate's name
server, which can then populate the zone with its own records and then
uses selectors like bar.foo. But only if the domain owner trusts the
delegate to sign for any address in the domain.)
I'll see about putting more detail in 4.1.2.
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.)
I'm not getting the distinction between the two threats here. It isn't
enough that dome domain's private key has been stolen, the attacker has
to have that private key. I see that as dramatically lowering the
likelihood of the second attack.
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.
Right, missed that one.
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.)
I see that as a special case of 4.1.6, "Denial-of-Service Attack Against
Verifier". How does that fit with 4.1.11, "Compromise of Key Server"?
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.
The way I'm using "chosen" here is different from "chosen ciphertext
attacks", so it may have been an unfortunate choice of words. What I
mean is that the attacker gets to choose the text being signed and
ultimately replayed.
The converse, akin to "known message replays", is what I call "signed
message replays" in 4.1.5. Does this cover it?
Nits & specific things:
=======================
I'll work on the nits and specifics and not respond directly to those.
Thanks for the detailed review.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org