Hi Jim,
Jim Fenton wrote:
I'll probably answer in more detail than you need, but anyway...
Not too bad - at least you stopped before the nits:-)
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(?)
Being informative or not doesn't make a difference so we either stick
to just referencing the charter page (though that URL will move over
time) or, better, we reference some conference paper about DKIM - is
there one at the RSA show, or, worse, we refer to the I-Ds and just
let everything hang in the editor's queue 'till they all pop out at
once. That last isn't the end of the world, so if there's no existing
referencable document, let's just refer to the I-Ds.
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"?
Not sure.
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.
I guess the concern is that some threats (e.g. the one-bit-gif) are
targeted at non-DKIM users once there are sufficient numbers of DKIM
users (or DKIM installations maybe since "user" is a bit ambiguous
here I suppose).
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.
Note that if you take the above route, then we don't have to nail every
last quibble about the definitions.
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.
I think this'd be good. But given the time frame we're trying to work
to, this is a potential rathole, since afaik, its basically a less
developed aspect of DKIM. If someone has a write-up of a more
detailed description of how this could work, it might be worth
starting a thread on that. Otherwise, I'm a bit afraid that this
could hold us up, either now doing the threats or later with the
base spec. (You'd be right if you got the impression that I'd be
happier were it possible to push this out to a later document.
But again, I recognise that this mightn't be possible.)
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.
Maybe its a bogus distinction, but let me try again:
Threat1: Compromise of one or more MTA private keys somewhere on the
Internet.
Likelihood: high, impact: medium.
Threat2: This message was signed by stolen private key.
Likelihood: low, impact: high.
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"?
Seems like a direct attack against the public key server to me, (if
its possible that is), in which case 4.1.11, but I'm fine with omitting
it unless it rings a bell with someone more familiar with DNS that I
am.
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?
Ah. The comment wasn't meant as a criticism but more that the phrase
you used reminded me of something that I think may be interesting.
(That it should be easy to extract a relatively predictable signed
message from a domain by peppering it with messages to which some
user will reply. I don't know now how to construct a concrete
attack against something using this, but I suspect it'll be possible.)
I guess leave it as-is for now unless someone comes up with something
concrete.
Cheers,
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org