Wrap TFM; start splitting sk.i up into more .i's.
[sovereign-keys.git] / issues / dos-attacks.txt
1 A. Denial of Service Attacks by writing to the Timeline.
2
3 Although we can reasonably assume that all mirrors have, say, 3TB of disk
4 space, a great deal more than required for active sovereign keys in the
5 foreseeable future, the possibility of attacks that might consume that space
6 and force the mirrors to store terabytes of junk indefinitely is serious.
7
8 Some of the kinds of evidence for sovereign keys can easily be generated for
9 an unbounded number of names.  For instance, if I have example.com, I can use
10 DNSSEC to register a.example.com, b.example.com, ... aa.example.com,
11 ab.example.com ... , etc.  The registration of this kind of stream of
12 sovereign keys (from within just example.com or perhaps a very large set of
13 domains) would constitute a problematic denial-of-service attack against
14 mirrors' supply of disk space.  
15
16 This kind of unbounded enumeration is normally more expensive for trusted
17 CA-signed evidence, but the attacks could still be performed by CAs, or by
18 attackers who compromise a CA.
19
20 AVAILABLE MITIGATION MEASURES
21
22   1. Restrict (DNSSEC) sovereign key registrations from freely enumerable
23   portions of the DNS hierarchy.
24
25   Only allow free, unlimited sovereign keys from those portions of the DNS space
26   where we are sure that registration fees apply.  The characterisation of
27   those subsets of DNS space will be an ongoing project.  For instance, if the
28   Libyan government started an enumeration attack, .ly would have to be
29   removed from this list.
30
31   Allow paid sk registrations outside of that portion of DNS space and/or
32
33   2. Allow sovereign key registrations in freely enumerable portions of
34   the DNSSEC hierarchy with a (paid) CA certificate.
35
36   3. Allow sovereign key chaining.  By this mechanism a sovereign key for
37   example.com can delegate to a.example.com, but this happens in X509 chains
38   and not on the timelines.  New users of a.example.com do not get full
39   protection against attacks by example.com.
40
41   4. Rate limit new entries on Timelines.  This is not a solution so much as a
42   way to buy time while figuring out which DNS registries/DNS registrars/CAs a
43   DOS is coming through and how to mitigate it.  A collective rate limit of
44   5GB/day would allow 2.5 million sovereign keys per day, significantly more
45   than the current number of domains registered each day, while providing up
46   to 600 days of attack-resistance.
47
48 The best solution is probably using all four of these measures simultaneously.
49 3 is probably the most complicated from an implementation perspective.
50
51 COST OF ATTACK UNDER SUCCESSFUL MITIGATION
52
53 Supposing that the design succeeds in requiring DOS attackers to pay for
54 something (a domain registration or CA certificate) for each new sovereign key
55 they write to a timeline.  Assuming that attackers must pay $5 for a 2kB
56 timeline entry, the cost of filling a 3TB mirror is ~$8 billion.  At that
57 point we could ask Verisign to purchase nice new raid arrays for all existing
58 mirror operators ;).
59
60 B. Denial of Service Attacks against Timeline Server bandwidth
61
62 Timeline servers can perform all of their operations over TCP.  This prevents
63 asymmetrical DOS attacks, but is far from sufficient.
64
65 Timeline servers need to remain available for the purposes of communication
66 with each other and updates to important mirrors.  Timeline servers should
67 therefore maintain a QOS priority arrangement that exchanges traffic with
68 other timelines before anything else, and with known mirrors in good standing
69 before unknown mirrors and clients.
70
71 C. Denial of Service Attacks against Mirrors
72
73 Unlike Timeline servers, which need only sign a new Timeline Freshness
74 Message from time to time, the protocol requires that Mirrors sign their
75 responses to each client's query.
76
77 This is a potential DOS mechanism, because even asymmetric key signature
78 operations are expensive.
79
80 One mitigation is that the protocol supports an unbounded number of cheap
81 mirrors.  Mirrors may be configured to only serve, or preferentially serve, a
82 bounded client base (such as the subscribers at a particular ISP).  
83
84 However, mirrors can cache responses to the most frequent queries they are
85 receiving (for instance, <what are the updates for facebook.com since X>,
86 where X is the last time facebook updated its sovereign key).