Wrap TFM; start splitting sk.i up into more .i's.
[sovereign-keys.git] / issues / transitional-considerations.txt
1 Transitional Considerations
2
3 In some hypothetical future state of the world, one might imagine that parties
4 purchasing domain names would also create sovereign keys for them at the same
5 time (or have their choice of service provider do so for them).  In the mean
6 time, however, it is necessary to consider how sovereign keys can be created
7 for some existing domains in an orderly fashion.
8
9 1. Protecting the Holders of Compromised Webservers against Sovereign Key
10 Creation
11
12 Today, an attacker who compromises a victim's DNS or web servers is able to
13 obtain or create PKIX-certified private keys or DANE DNSSEC-signed private
14 keys for the victim domain.  This is of course bad, but is presently a
15 somewhat-recoverable situation.  If the attacker used these ingredients to
16 create herself a sovereign key for the victim's domain, the attack might be
17 more-or-less permanent.  This is clearly very bad.
18
19 The Sovereign Key protocol offers domain holders a way to proactively protect
20 against this sort of situation (create a sovereign key with no protocols
21 registered for it, and store that key offline).  However only domain holders
22 who have taken this step, or those who have created real operational sovereign
23 keys, can benefit from this method.
24
25 Mitigation of the risk to unknowing domain holders will require extra steps
26 during the period of transition to sovereign key usage (which may be long).
27 During this period, timeline servers SHOULD apply the following additional
28 criteria before allowing a sovereign key to be created:
29
30   a. Check that the HSTS header is set for this domain, and that the HTTP
31      homepage of the domain redirects to HTTPS.  Check this from a number of
32      network endpoints, with a number of different client device types.
33      This is intended to greatly reduce the number of domains for which
34      sovereign keys can be created, to a group that have demonstrated a
35      knowledge of competent contemporary HTTPS server administration.
36
37      Attackers can of course enable HSTS on compromised webservers, but on
38      the overwhelming majority of existing domain names, such an action would
39      be highly visible to the webmaster, leading to breakage and
40      investigation.
41
42   b. Check for the presence of https://www.domain.com/request-for-sovereign-key.txt
43      (this precise contents of this file will be specified, but it will be
44      something like "I, the administrator of domain.com, hereby request that
45      a sovereign key be created for domain.com.  I understand that losing this
46      key means loss of control of this domain.  I promise that I have
47      three backups of the private key.  My requested public key is as follows:
48
49      <base 64 encoded key/key hash>
50
51      <link to Wikipedia or other multilinugal documentation on sovereign
52      keys>) over a two-week period before registration is signed.  This is
53      intended to provide some comparatively solid evidence to the
54      administrators of compromised webservers about an attacker's attempt to
55      create a sovereign key for their domain.
56
57   c. Over the two weeks prior to registration, send a number of notification
58      emails to the domains's WHOIS technical contact, addresses listed in its
59      X.509 end-entity certificate, and webmaster address, confirming the SK
60      request, pointing out the URL above, and offering a cancellation link.
61
62 It will be an empirical question whether these methods are sufficient to make
63 successful sovereign key creation attacks rare.  Drastic methods are available
64 if these incidents are too common.  One would be blacklists included in client
65 source code.  Another would be having clients poll (SafeBrowsing style) a
66 list of cancelled sovereign keys; such a list would need to be cross-signed
67 by a lot of parties in a lot of jurisdictions.
68