Subject: [ietf-dkim] some more comments on the threats draft

From: Stephen Farrell <[email-masked]>
Date: Tue, 10 Jan 2006 19:27:19 +0000

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

---

From: Dave Crocker <[email-masked]>
Date: Tue, 10 Jan 2006 18:06:51 -0800

> I admit, so I'm not sure. 

Actually, it reflects the problem of having a threats document really be 
something else.

If the threats document really were about threats and concepts, it would not 
have to cite DKIM specification specifics.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Jim Fenton <[email-masked]>
Date: Sat, 14 Jan 2006 12:00:03 -0800

I'll probably answer in more detail than you need, but anyway...

Stephen Farrell wrote:
> ------------------------------------------------------------------------
>
>
> General/bigger:
> ===============
>
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(?)
>   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"?
>   perhaps that could reduce the likelihood.
I mention DKIM users primarily because non-users are unlikely to notice
an attack on DKIM.
> 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.
> IESG) that the threats we've identified constitute a relatively complete list.
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.
> attacker then knows the non-DKIM recipients and can target those for additional
Right, missed that one.
> 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"?
> 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

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 15 Jan 2006 15:09:42 +0000

Hi Jim,

> I'll probably answer in more detail than you need, but anyway...

Not too bad - at least you stopped before the nits:-)

> 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.

> "messages from and entire domain or multiple domains"?

Not sure.

> I mention DKIM users primarily because non-users are unlikely to notice

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).

>> 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.

> 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.)

> 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.

> 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.

> 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.