5b90d1174444ffc273d5dbd22d11b55cdb9d884b
[sovereign-keys.git] / sovereign-key-design.txt
1 Sovereign Key Cryptography for Internet Domains
2
3 Peter Eckersley (pde@eff.org)
4
5 This document describes a method for implementing persistent, secure
6 associations between Internet domain names and public keys.  The method
7 bootstraps from and reinforces existing PKI techniques, such as trusted CA
8 certificates or DANE DNSSEC entries, to create `Sovereign Keys' which
9 are persistently associated with names. 
10
11 This document sets out the design of the Sovereign Key system, but is not
12 presently a complete specification.  For instance, it indicates the types and
13 semantics of variables and protocol messages, but does not necessarily specify
14 the encodings and file formats that must be used to transmit or sign them.  It
15 indicates a number of numerical parameters for the protocol, but does not
16 necessarily specify values that should be used for all of them.
17
18 Readers who are interested in the comparative features and design objectives
19 of this proposal and contemporary alternatives, may wish to read Appendix A
20 before continuing.
21
22 0. What are Sovereign Keys useful for?
23
24 0.a. Robust protection against "man in the middle" and server impersonation 
25      attacks, including CA-certified or DNSSEC-signed attacks
26
27 We propose that if a sovereign public key is registered for a particular
28 service (eg, HTTPS or SMTPS) on a particular domain, clients for that service
29 which understand Sovereign Keys MUST verify that operational public keys
30 (e.g., those at the end of X.509 certificate chains) have been cross-signed by
31 the Sovereign Key.  If they cannot verify a signature from the Sovereign Key
32 over the server's key, the client MUST refuse to transmit data to that server
33 and MAY warn the user that a verified connection cannot be established.  If a
34 client observes a Sovereign Key for a domain and protocol, the client MUST
35 also refuse to communicate over insecure variants of the registered protocols
36 (HTTP, SMTP, etc).
37
38 0.b. Automatic circumvention of attacks
39
40 User interface research has shown that it insufficient to warn users about the
41 presence of a server impersonation or man-in-the-middle attack.  A large
42 fraction of users will click around multi-step certificate warnings,
43 especially if that is the only way for them to get to their destination
44 [http://lorrie.cranor.org/pubs/sslwarnings.pdf,
45 http://research.microsoft.com/en-us/um/people/cormac/papers/2009/SoLongAndNoThanks.pdf].
46 With Sovereign Keys, the certificate warning interface MAY be removed, and
47 replaced with code that automatically routes around server impersonation,
48 man-in-the-middle, and connection blocking attacks.
49
50 The Sovereign Key protocol allows server operators to specify their preferred
51 routes for attack circumvention, which may include routing to specific IPs and
52 ports; routing via Tor; routing via a Tor hidden service; I2P or other
53 future/experimental protocols.
54
55 1. Timeline Servers
56
57 The Sovereign Key system involves a set of N (10-30) timeline servers. N
58 should be chosen to provide some diversity of jurisdictions, operational
59 philosophies and security implementations, and ideally to provide these
60 properties even if some of the servers are compromised/disabled.  N should not
61 be too large because the messages discussed in Section 4.a. will become
62 correspondingly large, and because the risk of dereliction as described in
63 4.b. increases.  These servers store verifiably read- and append-only data
64 structures in which the mappings between names and sovereign public keys are
65 stored.  
66
67 The reason these data structures are append-only is to ensure that once a
68 Sovereign Key has been legitimately claimed for a particular name, no other
69 other subsequent claimant can alter the original claim, even if they
70 compromise a CA or a portion of the DNSSEC hierarchy.  Append-onlyness is
71 ensured by having the server sign an incrementing serial number and a
72 monotonically increasing timestamp as part of each timeline entry.  Violation
73 of the timestamp monotonicity and serial number uniqueness properties of a
74 timeline server is detectable, and will cause all clients to cease trusting
75 the timeline server immediately, as described in Section 3 below.
76
77 The timeline servers exist for the sole purpose of recording and preserving a
78 correct history of claims to Sovereign Keys.  Clients believe the oldest claim
79 to a key for any given name plus any self-signed updates it has subsequently
80 published (which include revocations, renewals and other adjustments, all of
81 which are discussed below).  Claiming a key for a name requires evidence of
82 control in the DNS (either a CA-signed certificate or a key published by DANE
83 DNSSEC).
84
85 Clients can access claims to Sovereign Keys so long as 1 of the N timeline
86 servers remains intact.  In practice, clients do not usually query the
87 timeline servers directly; instead, they query one of M comprehensive mirrors
88 of the timelines (M >> N).
89
90 Each timeline server possesses a unique private/public key pair.  The public
91 keys of the timeline servers are shipped with clients, so that clients can
92 verify the authenticity of timeline entries. 
93
94 A claim to a new Sovereign Key that is stored in the timeline contains the
95 data listed below; the table also lists the estimated efficient compressed
96 storage/transmission size in bits.
97
98 PURPOSE             TYPE        FIELD              ESTIMATED ENTROPY (BITS)
99 --------------------------------------------------------------------------------
100 Monotonicity        uint64_t  : serial number      0
101                     uint64_t  : timestamp          25
102 --------------------------------------------------------------------------------
103 Sovereign Key       char[256] : name               50
104                     bool      : wildcard           1
105                     char[]    : key type           0.5
106                     char[]    : sovereign_pubkey   224-256 (assuming ECC)
107                     char[]    : protocols          200-300
108                     uint64_t  : expires on         25
109 --------------------------------------------------------------------------------
110 In case of          char[][]  : inheriting name(s) 50 
111 revocation
112 --------------------------------------------------------------------------------
113 Evidence            char[]    : cacertchain        9000-1300 (256 for a hash)
114 for claim           char[]    : DNSSEC_evidence    ?
115                     char[]    : claim_signature    1024-2048 (required, see below)
116 --------------------------------------------------------------------------------
117 Timeline signature    char[]    : signature          224-256
118
119 When compressed, a Sovereign Key backed by 1024 bit RSA evidence is about 1300
120 bytes, while one backed by 2048 bit RSA evidence is about 2000 bytes.
121
122 The "evidence for claim" fields are a CA-signed DER-encoded X.509 certificate
123 associating the name with the Sovereign Key, or DANE DNSSEC evidence
124 associating the name with the Sovereign Key, if that is available for this
125 TLD.  These show that at the time of entry to the timeline, the
126 sovereign_pubkey was genuinely associated with the name.  The timeline server
127 MUST verify that the X.509 certificate or DANE DNSSEC response is valid at the
128 time the Sovereign Key is created (though clients MAY verify this for
129 themselves in the future, too).
130
131 The timeline server MUST verify the OCSP status of the X.509 certificate before
132 issuing the Sovereign Key, but (in order to save space) the protocol does not
133 require that the OCSP response be included in the evidence field.
134
135 The claim signature protects against attacks such as the timeline server
136 modifying the wildcard field or spontaneously issuing a Sovereign Key from any
137 valid X.509 cert it finds.  The public key in the X.509 cert may be equal
138 to the sovereign_pubkey, in which case claim_signature is a self-signature.
139 It may also be different, which is useful if, for instance, you want to use an
140 ECC Sovereign Key but your CA won't issue a certificate for it.  We expect
141 this to be the common case.
142
143 The "inheriting names" are the names of other Sovereign Keys that may be used
144 to adjudicate the creation of a new Sovereign Key in case the first is
145 compromised and subsequently revoked.  Parties creating Sovereign Keys could
146 list any zero or more names: "verisign.com", "business.ru", "aclu.org", etc.
147 The holders of the Sovereign Keys for these /other/ names would inherit the
148 ability to re-register the name if and only if a self-signed sovereign
149 revocation occurs (revocation and related concerns are discussed later in this
150 section and in Section 6 below).
151
152 The "wildcard" flag is an optimisation.  Some names may wish to 
153 issue distinct Sovereign Keys for their subdomains.  In that case, the
154 wildcard bool should be FALSE.  If the wildcard bool is TRUE, then this
155 Sovereign Key is valid for all subdomains of "name".  For instance a wildcard
156 Sovereign Key for eff.org speaks for a.eff.org, a.b.eff.org, etc.  Note that
157 wildcard and non-wildcard Sovereign Keys may not coexist for any portions of
158 the DNS namespace, but that wildcard Sovereign Keys will be capable of other
159 sorts of delegation of authority for operational purposes, as discussed in
160 Section 5 below.
161
162 The "protocols" field is a list of strings ("https","smtps","imaps",etc)
163 denoting the services that must be cross-signed by the Sovereign Key on this
164 domain.  A service may optionally have a port number designating a
165 non-standard port for that service (eg, "https:8080").  The protocols field
166 may also contain the value "all", in which case clients should always expect
167 services on this domain to be authenticated with the Sovereign Key.  
168
169 Each string in the protocols list may optionally be suffixed by a
170 semicolon-delimited list of methods for alternative routing to that service.
171 For instance, if the protocols field were
172 ["https:8080;123.45.67.89:8080;ttbmov2dezfs2fln.onion", "smpts",
173 "imaps;711E9E5711A6E28E2A27DE23B7C70C91D39908D0.exit"], that would specify
174 that a connection to https on port 8080 may alternatively be routed to the IP
175 address 123.45.67.89, or to the specified .onion address, in decreasing order
176 of preference; that a connection to the domain via IMAPS could be routed via a
177 particular tor exit node at MIT (similar to exit enclaving, but secure against
178 false DNS responses); however no alternative route to this domain's SMTPS
179 server is available.
180
181 The timeline's signature is computed over and authenticates all of the
182 fields.  Such signatures may be performed offline.
183
184 Compressed timeline entries are ~1.5kB (without an OCSP response in the
185 evidence). Sovereign Keys for the 2 x 10 ^ 8 domains currently in existence
186 could be stored on a timeline in around 300GB of disk space.  
187
188 Timelines may also contain three other kinds of entries:
189
190 * Incorporation-by-reference of other timeline servers' entries
191
192 The timeline servers might have their private keys compromised or revoked, in
193 which case they will die.  In order to make Sovereign Keys robust against such
194 events, a client registering a new name with one timeline server should request
195 that others incorporate a copy of the registration by reference.
196
197 Incorporation by reference is a timeline entry of this form:
198
199    Serial number
200    Timestamp
201    Other timeline's name/id
202    Serial number of other timeline's entry
203    Hash of other timelines's entry
204    Timeline signature
205
206 The timeline server MUST cache a copy of the other timeline's entry when it
207 performs incorporation-by-reference.
208
209 * Revocations:
210
211    Serial number
212    Timeline Timestamp
213    Time of revocation       }
214    Sovereign Key name       }  Provided by Sovereign Key holder
215    Sovereign Key signature  }
216    Timeline signature
217
218
219 * Reissuance of revoked names
220
221    Serial number
222    Timestamp
223    New Sovereign Key fields 
224    Future "in case of revocation" fields
225    Evidence (signature from a previous "in case of revocation" name)
226    Timeline Signature
227
228 Timelines MUST NOT accept a reclamation unless they include or
229 incorporate-by-reference a revocation of the old Sovereign Key.
230
231 * Alterations of protocols
232
233    Serial Number
234    Timestamp
235    Name                             }
236    New value for Protocols field    }   Provided by Sovereign Key holder
237    Sovereign Key Signature          }
238    Timeline Signature
239
240 For DOS-prevention purposes, timeline servers MUST NOT accept more than a
241 certain number of revocations or protocol alterations for a Sovereign Key per
242 unit time.  The values of these parameters are to be determined (eg 5 protocol
243 alterations per month, or start with a budget of 5 allowed alterations, and
244 replenish this by one per fortnight).
245
246 * Alterations of the Timeline's Trust Root
247
248 Timeline servers SHOULD copy and update their list of trusted Certificate
249 Authorities from one of the major client libraries.  Timeline servers MUST
250 publish a record of which root CAs they trust over time, using the
251 following timeline entries:
252
253   * This timeline server trusts a new root Certificate Authority
254
255     Serial Number
256     Timestamp
257     Certificate Authorities DER-encoded X.509 certificate
258     CA Update Serial Number
259     Timeline Signature
260
261   The "CA Update Serial Number" is a 2 byte number that begins at zero and is
262   incremented by one every time the timeline notes that it is adding or
263   removing a trusted root CA.
264
265   * Removal of trusted root Certificate Authority
266
267     Serial Number
268     Timestamp
269     Serial Number of this CA when first added to this timeline
270     Secure hash of root CA certificate
271     CA Update Serial Number
272     Timeline Signature
273
274 2. Mirroring Timelines
275
276 Mirrors exist for performance and reliability reasons.
277
278 Mirrors keep full, up to date copies of all the trusted timelines.  A mirror
279 SHOULD be bootstrapped by BitTorrent, hard-disk-over-snail-mail, or a similar
280 bulk data distribution mechanism that does not require a large download from
281 the timeline servers.  Data storage is cheap enough that a $100 disk will
282 have plenty of room for a mirror server for the foreseeable future.
283
284 Mirrors are identified by an IP address, a port number, and a public key.
285
286 Timeline servers must respond to mirror queries of the form "send me all of
287 your timeline entries since Serial Number S".  Appended to that response
288 should be a Timeline Freshness Message (TFM):
289
290 Timestamp
291 Highest Serial Number to Date
292 Highest CA update Serial Number to Date
293 Timeline Key Signature
294
295 A mirror (or a client) might observe a timeline server to have "reneged".  This
296 occurs if:
297
298  - the mirror or client sees two different signed entries on the same timeline
299    with the same serial number, or 
300
301  - two different entries on the same timeline that violate timestamp
302    monotonicity (ie a signed entry with a higher serial number but a lower
303    timestamp), or 
304
305  - a timeline freshness message with a lower timestamp and higher serial
306    number than a previously-observed entry on that timeline, or
307
308  - an entry for a new Sovereign Key that is not validly signed by a chain from
309    one of the timeline's root CAs or by a chain from the DNSSEC root
310
311 If a mirror observes a timeline to have reneged it MUST:
312
313  - Store a copy of the contradictory signed timeline statements
314  - Cease trusting that timeline server
315  - Add this reneged information to a structure of bad timeline servers, which
316    can be queried by clients
317
318 3. Renegation Tracking and Synchronisation
319
320 Protocol messages contain a "renegation tracking" field.  This 32 bit number
321 are the low order bits of a secure hash of the list of previously-trusted
322 timeline servers that this mirror or client knows to have reneged.  If a client
323 or mirror receives a message with a renegation tracking number that is
324 different to its own, it MUST enter a renegation synchronisation phase of the
325 protocol (if renegation synchronisation fails with a given peer, the client or
326 mirror is not obliged to repeat synchronisation with that peer).
327
328  [Aside: the design above assumes that implementors can agree on a master
329  repository of timeline servers that are or were once in use.  We do not believe
330  this is a problematic requirement, but alternative suggestions are welcome]
331
332 Renegation tracking involves sending a list of the timelines that this
333 client/mirror believes to have reneged; the peer replies with a list of
334 additional timelines that it believes to have reneged, along with the evidence
335 that renegation occurred, and a list of requests for evidence.  The initiating
336 client/mirror then replies with evidence of renegation for the renegations the
337 peer did not know about.  At the end of this process, both participants should
338 have the same list of reneged timelines (and the same renegation tracking
339 field).
340
341 4. Querying Timeline Mirrors
342
343 4.a. Queries to Mirrors
344
345 Clients query one of the M comprehensive mirrors of timelines with a query
346 that asks "what are all the timeline entries that pertain to name X since
347 entry Y?"   The mirror replies with a response saying "as of time T, I have
348 the following entries on various timeline servers pertaining to X: <list of
349 entries> <list of relevant Timeline Freshness Messages>".  This message is
350 signed by the mirror's key.  For performance reasons, clients which have
351 already cached the history of X may use an alternative query form,  "what
352 timeline entries for name X have appeared since these? [(timeline ID,
353 entry),(timeline ID, entry) ..] ".
354
355   [Note that the size of this server response is fairly large because of the
356   TFMs.  For 20 timeline servers with 224 bit ECDSA keys and an efficient
357   encoding for the other data in the TFMs, the TFMs would take up about 1200
358   bytes.  For 30 timeline servers with 256 bit ECDSA and naive 8 byte encodings
359   for timestamp and timeline entry numbers, the TFM response overhead would be
360   2400 bytes]
361
362 4.b. Satisfactory Mirror Responses
363
364 Clients SHOULD use the following (Pythonic pseudocode) algorithm for querying
365 mirrors:
366
367 T1 = 24 hours    # No querying necessary if records are fresher than this
368 T2 = 48 hours    # 24-48 hours: acceptable, but query proactively
369 T3 = 1 week      # Records older than an week are bad news, though we will
370                  # somewhat tolerate a small number of dysfunctional timelines 
371                  # in this state
372 T4 = 2 weeks     # Once a few timelines reach this age, we fail open
373
374 MAX_DERELICT_TIMELINES=2    # Timelines are derelict if nobody is seeing updates
375                             # from them.  We will tolerate this number of them
376
377 N_RETRIES=5      # Number of mirrors to try if we aren't getting fresh enough
378                  # responses
379
380 number_fresh=0
381 for s in timeline_servers:
382     if s.entries_for_name(name).freshness > getcurrenttime() - T1:
383       number_fresh +=1
384 if number_fresh == len(timeline_servers):
385     return SUCCESS
386
387 for n in range(N_RETRIES):
388   
389    # START_QUERY_ATTEMPT
390    if len(GOOD_MIRRORS) == 0:
391      return FAILURE
392    m = random.choice(GOOD_MIRRORS) # clients MAY prefer mirrors which are 
393                                    # provided by their ISP or network, or 
394                                    # may select from a global list
395    response = m.query(name)
396    number_fresh_enough = 0
397    number_stale = number_very_stale = 0
398    for s in timeline_servers:
399        s.entries_for_name(name).update_from_response(response)
400        freshness = s.entries_for_name(name).freshness
401        if freshness < m.best_freshness_observed_for_timeline(s):
402            # This mirror just gave us a /less/ fresh response for this name 
403            # than it  had done for some other name.  Never use it again.
404            GOOD_MIRRORS -= m
405            goto # START_QUERY_ATTEMPT
406
407        lag = getcurrenttime() - freshness
408        if lag < T2:
409            number_fresh_enough += 1
410        else:
411            if lag > T3:
412              number_stale += 1
413            if lag > T4:
414              number_very_stale +=1
415        
416        if (number_fresh_enough >= len(timeline_servers) * 0.8) AND 
417           (number_stale <= MAX_DERELICT_TIMELINES):
418            return SUCCESS
419
420 if number_very_stale > MAX_DERELICT_TIMELINES:
421     # If 3 or more non-reneged timeline servers have not been updated for 2
422     # weeks, we are under successful attack.  Fail open.  
423     return FAILURE
424 else:
425     return SUCCESS
426
427
428 Clients SHOULD cache the responses they get from mirrors, and MUST check that
429 mirror replies are consistent with these cached entries.  If a mirror provides
430 a response whose contents omitted entries for the queried name X that predate
431 the relevant freshness messages and are cached by the client, the client MUST
432 stop trusting this mirror.
433
434 4.c. Privacy Considerations When Querying Mirrors
435
436 Clients' queries to mirrors raise privacy issues that are similar to those
437 raised by queries to DNS servers.  Because the wire format will be TLS or a
438 UDP protocol that provides confidentiality, there will be slightly better
439 privacy with respect to network attackers; however, the mirror is in a
440 position to learn which IP address is querying which name.
441
442 A minimal way to address this would be to have ISPs run mirrors much as they
443 tend to run DNS recursive resolvers.  However there is the option of doing
444 better if we add the following: 
445
446   mirrors SHOULD listen on port 443 and on a special SK mirror port <MP>.
447
448   Clients may send a mirror a request to proxy in place of a normal query.  If a
449   mirror receives such a request for a mirror server on port <MP>, it MUST make
450   forward the connection to the requested mirror on that port.
451
452 4.d. Performance Considerations When Querying Mirrors
453
454 Superficially, the query to mirrors may appear increase the latency of TLS
455 connections.  However, this should only be true in corner cases, for the
456 following reasons:
457
458   1. When setting up a TLS connection to a service, clients must make at
459   minimum three network roundtrips: a DNS query, the three way TCP handshake,
460   and a TLS handshake (ignoring the possible roundtrips for DNS recursion and
461   OCSP).  This happens in parallel with Sovereign Key operations, not in
462   series.
463
464   If the client queries a mirror, it must make at least 1 roundtrip (over UDP
465   or a persistent TLS connection) and possibly 3 roundtrips (for a new TLS
466   connection) to fetch a Sovereign Key history.  No blocking of communications
467   occurs unless this operation is still in progress once the main TLS client
468   connection is ready to send encrypted data.  So, provided the latency of the
469   Sovereign Key query is less than or equal to the latency of establishing the
470   TLS session in the first place, it will add no further latency.  With
471   nearby, high-performance mirrors this could be achieved with TLS; with a
472   lighter-weight UDP protocol or persistent TLS connections it could be
473   achieved with slower, more distant mirrors.
474
475   2. The common case is that clients only query mirrors for a given name at
476   most once every 24 hours, in order to check for Sovereign Key revocations.
477
478   3. The algorithm described in Section 4.a. can trigger up to five queries to
479   mirrors.  This should not be normal: this case only applies when the client
480   is talking to out-of-date mirrors (it should find better ones) or if several
481   (3 or more) of the timeline servers has experienced an outage of a week or
482   more.
483
484 5. Use of Sovereign Keys on TLS servers
485
486 As discussed in the introduction, the first use for Sovereign Keys is as an
487 alternative, more reliable method of verifying the keys used by TLS servers.
488 This requires that the operational key be cross signed by the sovereign
489 private key, in parallel with existing (PKIX/DNSSEC) key verification
490 methods.  The Sovereign Key may also be used to cross-sign a CA certificate
491 that chains to the operational end-entity certificate; one reason for doing
492 this is that it enables a wildcard SK for a large operational domain to
493 delegate to private CA keys for subdomains.
494
495 At present we believe the best method for cross-signature will be to append
496 an addition certificate to the X.509 chain.  This should not be a real
497 certificate, but simply a data storage method for the cross signature.  We
498 will need to register a new OID for an X509 v3 extension to store the
499 cross-signature.  The Subject, Issuer, Key, etc in this certificate can be
500 anything (and should therefore be brief).  If CAs cooperate with the sovereign
501 key system, they could add the cross-signature extension to existing
502 end-entity certificates, thereby avoiding the need to append an extra
503 certificate to carry the cross-signature.  CA cooperation is not required, of
504 course.  
505
506 Certificates that carry cross-signatures from Sovereign Keys may also point to
507 OCSP servers, which allow the Sovereign Keys to revoke operational keys if
508 desired.  Alternatively, these certificates can have short validity windows,
509 and they can be deployed on a rapidly rotating basis.
510
511 A client performing certificate verification that knows about Sovereign Keys
512 MUST default to bypassing other host authentication mechanisms if (1) it
513 observes a Sovereign Key certificate in the chain presented by the server or
514 (2) it has previously observed and cached a Sovereign Key for this name and
515 protocol combination.
516
517 6.  Operational Considerations Related to Key Loss and Revocation
518
519 Because the Sovereign Key design allows domain operators to reduce the number
520 of third parties who can launch attacks against their services to zero, it has
521 the property that if a domain holder /loses/ their sovereign private key, they
522 will probably lose the ability to switch to new operational keys, or may even
523 lose control of their domain, until the Sovereign Key expires!
524
525 Several measures and strategies are recommended to minimise this risk.
526 Overall, these measures should err on the side of exposing the private key to
527 being copied by attackers (which is a recoverable situation) instead of losing
528 all copies of the private key (which may not be recoverable before expiry).
529
530 We believe there are at least two workable approaches for domain holders:
531 relying on service providers to prevent key loss, or storing multiple backups
532 themselves.
533
534 If the domain holder selects a service provider that they are willing to
535 trust, this third party can escrow and back up their keys, manage revocation
536 and reissuance, etc.  For many domain holders this will be the preferred
537 option.
538
539 If the domain holder wishes to manage their own Sovereign Keys, they must
540 ensure that they have sufficient backups to mitigate the risk of domain loss
541 via Sovereign Key loss.  Server setup software which generates and registers
542 Sovereign Keys SHOULD make at least three redundant backups of the sovereign
543 key before it is transmitted to a timeline server.  Good vectors for backups
544 could include local mass storage devices, scp'd copies, email copies, or
545 printed hardcopies.  
546
547 7. Governance
548
549 Because the most essential security properties in the Sovereign Key design are
550 cryptographically verified within the protocol, the degree of governance this
551 mechanism would require is lower than for other security-affecting Internet
552 infrastructures, such as the X.509 Public Key Infrastructure or the Domain
553 Name System.
554
555 Nonetheless, a governance mechanism may be required to:
556
557 - monitor timeline servers' compliance with requirements that are not verified
558   within the timeline itself (such as preservation and checking of OCSP
559   responses during SK registration, or running ntpd to maintain a reasonably
560   accurate clock).
561
562 - monitor timeline servers' availability and their ability to push updates to
563   mirrors satisfactorily.  If a timeline server is close to becoming derelict
564   (per Section 4.b), notify client implementors so that they can consider
565   removing the timeline server from their list.
566
567 - maintaining a master list of all of the timeline servers that have ever been
568   trusted by deployed implementations of the protocol, for the renegation
569   tracking purposes discussed in Section 3.
570
571 - maintain a list of TLDs where unbounded free registration is documented or
572   from which timeline-writing DOS attacks have been observed, and a list of
573   Certificate Authorities which issue unbounded free certificates or which
574   have signed timeline-writing DOS attacks (see issues/dos-attacks.txt)
575
576 8. Other Operational Considerations
577
578 A number of operational and implementation issues are presently
579 discussed in separate documents in the issues/ directory.
580
581 9. Acknowledgements
582
583 Many people have offered valuable advice, commentary and suggestions on this
584 design.  These include most especially Dan Auerbach, John Adams, Jesse Burns,
585 Roger Dingledine, Brad Hill, Jeff Hodges, Dan Kaminsky, Adam Langley, Ben
586 Laurie, Bob Lord, Tom Lowenthal, Chris Palmer, Robert Ransom, Brian Smith,
587 Seth Schoen, Andy Steingruebl, Aaron Swartz, Brad Templeton, and Jered
588 Wierzbicki.  In most cases their advice was offered in their individual
589 capacities, and does not indicate any endorsement of this design.
590
591 APPENDIX A: FEATURE COMPARISON TO OTHER PROPOSALS FOR MITIGATING ATTACKS ON
592 TLS VIA CAs
593
594 A.1. Compared to publishing keys or key hashes in HTTPS headers
595
596 Various proposals have been made to publish commitments about future TLS
597 certificate chains via an HTTPS header.  These proposals come in different
598 flavours: one could commit to use a particular set of trusted CAs, or to some
599 other key that (much like a Sovereign Key) will be used to cross-sign whatever
600 operational keys this domain will use in the future.
601
602 Depending on which flavour of HTTPS header one is discussing, the SK design has
603 the following advantages:
604
605 - It works for SMTPS, IMAPS, POPS, XMPP, and other non-HTTP protocols
606
607 - An attacker who briefly compromises a webserver may not issue a header which
608   causes clients to cease trusting the legitimate server for an indefinite
609   period of time (this is most true if the domain already has a
610   Sovereign Key; see also issues/transitional-considerations.txt).
611
612 - Clients are not vulnerable to attacks upon first connecting to a domain, a
613   consideration that is especially important for smaller domains and in places
614   where Internet cafes remain an important type of client infrastructure.
615
616 - Compared to those variants of header pinning that commit to a set of trusted
617   CAs, once a Sovereign Key has been created, the holder does not need to
618   trust /any/ CAs in the future if she does not wish to.
619
620 - Compared to headers that commit to a particular cross-signing key, the
621   Sovereign Key design has a coherent revocation mechanism.
622
623 Put another way, the Sovereign Key design extends the header-based approach
624 to resolve a number of problems and limitations.
625
626 A.2. Compared to DANE DNSSEC
627
628 Sovereign Keys are compatible with, and improve the security of, the use of
629 DANE DNSSEC to publish signed keys for domains.
630
631 Although when compared to PKIX, DANE DNSSEC reduces the attack surface for any
632 given domain, it remains the case that a very large number of parties can
633 attack various domains.  For instance, google.ae could be attacked by the
634 United Arab Emirates' ccTLD registry or by anyone who compromised it; bit.ly
635 could be attacked by Libya's ccTLD registry of by anyone who compromised it;
636 ICANN's new gTLD policy
637 (https://secure.wikimedia.org/wikipedia/en/wiki/Generic_top-level_domain#June_20.2C_2011_vote_on_expansion_of_gTLDs)
638 will introduce hundreds of new top level registries, any of which would become
639 a point of attack for sites below it.
640
641 Compared to DANE DNSSEC on its own, the Sovereign Key design removes these
642 several hundred (or several thousand) points of attack against connection
643 security.
644
645 It also has the advantage of providing an optional mechanism for circumventing
646 attacks when they occur.
647
648 A.3. Compared to Perspectives/Convergence
649
650 Perspectives and Convergence are capable of defending against a significant
651 fraction that are possible against PKIX.  But these designs suffer from
652 several disadvantages:
653
654  - They raise false-positive alarms when a subset of a domain's servers switch
655    to an alternative certificate (we have observed this situation when major
656    financial domains have experimentally deployed alternative certificates
657    signed by alternative CAs).
658
659  - Generalising from the above problem, Perspectives and Convergence rely on
660    parties other than the domain holder to characterise what state the
661    domain's operational deployment /should/ be in 
662    (http://www.thesecuritypractice.com/the_security_practice/2010/04/perspectives-on-perspectives.html)
663    
664  - These designs produce false-negatives when attacks are visible from all
665    network endpoints (this can be the case, for instance, attacks via DNS
666    registrars, authoritative DNS servers, or BGP).
667
668 A.4. Compared to requiring CAs to publish lists of the certificates they have
669 signed for a brief period before clients will trust the certificates
670
671 In a sense, the Sovereign Key design is an extension of this concept:
672 CA-signed certificates are published to the timeline servers. 
673
674 - The Sovereign Key design has a scalable, fairly worked-out mechanism for
675   distributing the large volume of key and certificate material that appears
676   per unit time.
677
678 - The Sovereign Key design provides stronger protection for small and medium
679   sized domains, that may not have the resources to continually monitor and
680   understand what certificates are being issued for their names.