idnits 2.17.1 draft-ford-trans-witness-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2015) is 3083 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Public Notary Transparency Working Group B. Ford 3 Internet-Draft EPFL 4 Intended status: Experimental October 20, 2015 5 Expires: April 22, 2016 7 Collectively Witnessing Log Servers in CT 8 draft-ford-trans-witness-00 10 Abstract 12 This document proposes a backward-compatible extension to CT enabling 13 log servers to obtain compact collective signatures from any number 14 of well-known "witness" servers, which clients can check without 15 gossip to verify that log server records have been widely witnessed. 16 Collective signatures proactively protect clients from man-in-the- 17 middle attackers who may have stolen the private keys of one or more 18 log servers, even if the attacker controls the client's network 19 access, the client is unwilling to gossip for privacy reasons, or the 20 client does not wish to incur the network bandwidth and/or latency 21 costs of gossip. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 22, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Rationale . . . . . . . . . . . . . . . . . 2 58 1.1. The Challenge of Keeping Logs Honest . . . . . . . . . . 2 59 1.2. Proactive Witnessing of Logs . . . . . . . . . . . . . . 4 60 1.3. Efficient Proactive Witnessing with Collective Signatures 5 61 2. STH Collective Signing Extension . . . . . . . . . . . . . . 5 62 2.1. Availability and Signing Thresholds . . . . . . . . . . . 6 63 2.2. Identity of a Log Server's Witness Group . . . . . . . . 6 64 2.3. Evolution of Witness Groups . . . . . . . . . . . . . . . 7 65 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 4.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction and Rationale 73 Certificate Transparency's main security benefit fundamentally relies 74 on public logging of certificates, allowing certificate owners and 75 clients to cross-check and detect certificate misuse. The log 76 servers responsible for this public logging unfortunately represent a 77 new potential class of Single Point of Failure (SPOF), whose private 78 keys may become a new potentially attractive hacking target. For 79 example, if a hacker or powerful adversary were to obtain both a CA's 80 private key and a log server's private key, then the combination of 81 those two keys can potentially be used in Man-In-The-Middle (MITM) 82 attacks against unwitting clients by creating not only falsified 83 certificates but falsified logs (including fake SCTs and STHs) solely 84 for the consumption of the victim. 86 1.1. The Challenge of Keeping Logs Honest 88 While CT includes a gossip protocol to help "keep logs honest" and 89 enable nodes to cross-check their worldviews, gossip can protect only 90 well-connected hosts that are able to, willing to, and can devote the 91 time to communicate regularly with multiple independent monitor and 92 auditor servers on the Internet in order to cross-check the structure 93 and consistency of observed logs. This well-connectedness assumption 94 can fail to hold - or fail to be useful - in a variety of scenarios: 96 o If the client is located in a repressive country in which 97 essentially all available network access is controlled by a 98 government-imposed firewall that persistently MITM-attacks one or 99 more clients and blocks access to independent auditors and 100 monitors outside the country, then the attacker can separate the 101 victim clients from the well-connected Internet and prevent 102 detection for a potentially extended period of time (e.g., until 103 one of the targeted clients leaves the country). 105 o If the attacked client is a non-mobile device (e.g., a desktop PC) 106 always connected via the same attacker-compromised network access 107 path, then an attacker can similarly keep the victim persistently 108 oblivious to the difference between its CT worldview and the well- 109 connected world's. 111 o Even when feasible, unrestricted gossip can compromised privacy, 112 forcing on clients an unfortunate choice between greater security 113 and worse privacy (by using one or more trusted auditors that 114 effectively learn the client's browsing behavior) or greater 115 privacy and worse security (by declining the use of a trusted 116 auditor and hence being unable to cross-check SCTs that may have 117 been signed by compromised log-server keys). 119 o Even when feasible, gossip takes time and consumes network 120 bandwidth, making it impractical for most applications (e.g., web 121 browsers) to delay the acceptance and use of a certificate until 122 gossip-based cross-checking of the certificate has been performed. 123 This inherently leaves a window of vulnerability between exploit 124 and detection, which a savvy attacker can use to obtain the "keys 125 to the kingdom" within even a short window (e.g., a critical 126 password communicated via SSL). 128 o It has been proposed to use CT to help increase the security of 129 software distributions as it does for certificates - but if an 130 attacker can use a stolen pair of CA and log-server keys "even 131 once" to convince a victim to accept a falsified software update, 132 then that software update can simply disable CT or more subtly 133 modify its configuration to ensure that future gossip by the 134 victim will not notice anything amiss or raise an alarm. 136 o If the client is a stateless mobile device - such as a laptop 137 running the Tor-based Tails software distribution used for 138 anonymous communication by journalists, whistleblowers, and 139 dissidents - then the mobile device might be MITM-attacked while 140 the victim is at a compromised Wifi cafe, and fail to detect any 141 inconsistency in CT's worldview when it is next booted at a 142 different network access point due to the (deliberate) loss of 143 state. 145 One existing way to raise the bar to the attacker is to require CT 146 certificates to contain SCTs from multiple independent, well-known 147 log servers. Indeed, Google Chrome already requires three SCTs for 148 EV certificates. However, it is not clear that hacking or otherwise 149 obtaining even three log server keys is necessarily out of the reach 150 of some powerful but realistic attackers. Furthermore, if any 151 version of any CT-enabled client accepts (perhaps non-EV) 152 certificates with a single SCT, then a MITM attacker holding even a 153 single log-server key can form a "downgrade attack", impersonating a 154 site whose proper certificates normally have multiple SCTs but 155 presenting the victim with a fake (non-EV) certificate with only one 156 SCT. 158 1.2. Proactive Witnessing of Logs 160 To strengthen CT and address scenarios such as those above, we would 161 prefer that clients (as potential attack victims) be able to check 162 proactively, rather than only retroactively via gossip, whether an 163 SCT or the log tree it resides in has been "widely witnessed" in 164 public, e.g., by the well-connected cloud of audit servers that CT 165 already assumes will exist to check each log server for misbehavior 166 or equivocation. This would ensure that even a MITM attacker holding 167 a CA key and one or a few log-server keys could not make a client 168 accept a fake log without also compromising a (likely significantly 169 larger) number of each log's cloud of auditors as well. 171 As a first straw-man solution, we might demand that log servers not 172 only sign SCTs themselves but, while generating an SCT, communicate 173 with a threshold number of servers among some well-known group of 174 "co-signing auditors" which we will call "witnesses", and include 175 those witnesses' signatures in the SCT along with the log-server's 176 own signature. This would multiply the size of each SCT by a 177 potentially substantial factor, however, and similarly multiply the 178 computational cost on clients to check these signatures (which may 179 result in a non-trivial power cost on mobile devices). Furthermore, 180 the log-server would need to delay the signing of each SCT to allow 181 for active, online communication with its witnesses, which may add 182 unacceptable delays to SCT creation and may create scalability and 183 performance challenges if the log-server needs to create and log new 184 SCTs at a high rate. 186 A second straw-man solution addresses the last problem above by 187 expecting log servers to obtain a number of co-signatures from 188 witnesses only on STHs, rather than on individual SCTs. This keeps 189 SCT creation quick and lightweight, imposing online communication 190 costs on only the relatively infrequent and delay-insensitive STH 191 generation operation, which needs to be done only once every few 192 minutes to log an arbitrarily large batch of new SCTs. Obtaining co- 193 signatures on STHs in this way will protect clients from the types of 194 MITM attacks discussed above provided a mechanism is also added to CT 195 by which clients can request from web sites and check inclusion 196 proofs to verify the relationship between a (singly-signed) SCT and a 197 (multiply co-signed) STH. However, while this is a step forward, it 198 still multiplies the number of expensive signature-checks clients 199 must perform when receiving such an STH from a server. 201 1.3. Efficient Proactive Witnessing with Collective Signatures 203 To make proactive witnessing practical and efficient at larger 204 numbers of witnesses - and hence higher security levels - we would 205 like to "compress" all of an STH's (potentially many) witness 206 signatures into one. Multisignatures, theoretically well-understood 207 variations of standard signing schemes, already provide this 208 capability in principle [MULTISIG]. These schemes do not generally 209 scale beyond small signing groups, providing a limited advantage over 210 simply attaching multiple separate signatures as discussed above. 212 However, methods are now available to scale multisignature generation 213 efficiently to hundreds or thousands of participants, through the use 214 of communication trees and other optimizations [COSI]. In this 215 approach, a log server coordinates with a potentially large number of 216 participating witness servers to form and attach a single collective 217 witness signature to each STH. Clients verifying the STH (or an SCT 218 with an inclusion proof rooted in the STH) need normally perform only 219 two expensive public-key operations: one to check the STH's 220 conventional individual log-server signature, the other to check the 221 collective signature of the witnesses. The log-server's individual 222 signature could in principle be rolled into the collective signature 223 as well, but keeping them separate simplifies backward compatibility. 225 2. STH Collective Signing Extension 227 To support collective signing of STHs, we specify a new 228 SthExtensionType (value TBD), whose content is a collective signature 229 generated by one round of the CoSi colllective signing protocol 230 [COSI] initiated by the log-server but run with the cooperation of 231 the log-server's well-known group of public witnesses. 233 CT's current mechanism for STH extensions presents a minor challenge 234 in that all extensions are defined as being covered by the log 235 server's conventional digital signature (see the definition of 236 SignedTreeHead). This implies that to include a collective witness 237 signature as an SthExtension, the log-server must form the collective 238 witness signature before computing its own individual signature over 239 the full STH content including the witness signature. This in turn 240 implies that the log-server must invoke the CoSi protocol to sign a 241 slightly different version of the SignedTreeHead content, with the 242 collective witness signature extension omitted (necessarily since it 243 hasn't been computed yet). 245 A potentially cleaner way to address this issue would be to divide 246 the SthExtensionType namespace into designated ranges denoting 247 "signed" versus "unsigned" extensions, the latter being explicitly 248 excluded from the message on which either individual signatures or 249 collective signatures are computed. This would allow the STH's 250 individual and collective signature to be computed more consistently 251 on the "same" SignedTreeHead content. 253 2.1. Availability and Signing Thresholds 255 A natural operational risk is that a log-server might at a given time 256 find that one or more of its well-known witness servers is offline. 257 The CoSi protocol incorporates availability protection mechanisms 258 ensuring that the initiator (the log server in this case) can produce 259 a valid collective signature regardless of which or how many witness 260 nodes are only, but the produced signature will contain metadata 261 documenting which witness nodes were offline at STH-signing time and 262 enabling clients to verify the signature without those witnesses' 263 signature contributions. 265 A benefit of this availability protection mechanism is that the log 266 server can protect its own progress from unreliability and even DoS 267 attacks on or by witnesses, in principle even if many, most, or all 268 witnesses go offline. It is then ultimately up to client security 269 policy to determine how many witnesses may have been offline (or must 270 have been online) during signing in order for the client to trust the 271 STH. 273 A cost of this availability protection mechanism, however, is that 274 the size and verification cost of the collective signature is 275 proportaional to the number of witnesses that were missing at signing 276 time. For this reason, log-server operators are expected to choose 277 reliable witness servers run by competent, respected operators who 278 can be expected to keep their witness servers online consistently. 279 Provided almost all witness servers are online at any given time, the 280 produced STH collective signature is barely larger than a single 281 individual signature. 283 2.2. Identity of a Log Server's Witness Group 285 A log-server's group of witnesses cannot be a "wide-open" group, 286 since an attacker who can add any number of bad witnesses to the 287 group could perform a Sybil attack by adding a threshold number of 288 malicious witnesses that collude to produce collective signatures 289 that clients will accept. Thus, the operational expectation is that 290 log-servers specify a public, relatively stable, reputable, and 291 transparent set of witness servers for the log server to use. 293 In order for clients to check the log's collective witness 294 signatures, the clients must of course "know" the group of witnesses 295 with which the log server collectively signs its STHs. For this 296 purpose, clients that support collectively-signed STHs must include 297 in their roots of trust, alongside the log-server's public key, a 298 collective public key representing the aggregate of all the log- 299 server's witnesses. Like collective signatures, this collective 300 public is small and independent of the number of witnesses, amounting 301 to a single elliptic-curve point and a single cryptographic hash. 302 (The hash represents the root of a Merkle tree containing all witness 303 servers' individual public keys plus additional data needed in the 304 availability protection mechanism [COSI]). 306 2.3. Evolution of Witness Groups 308 A log server's set of witnesses must also of course change 309 occasionally, perhaps once per year in the long-term, or somewhat 310 more frequently during initial development and testing. Just as 311 conventional CA and log-server keypairs are typically valid for 312 overlapping multi-year windows, a log-server's collective public key 313 may be refreshed and gradually rolled over in similar fashion, via 314 the usual process of updating the relevant client software (e.g., web 315 browser) containing the log server in its root of trust. 317 Collective signing presents a potentially more attractive 318 alternative, however. When it comes time to evolve a log server's 319 witness group, the log server operator first produces and announces 320 the public key for the new witness group. This new collective 321 witness key can and perhaps should be based on new individual public 322 keys freshly generated by the individual witness servers. Then, as 323 the final collective signature produced in the old group, the log 324 server initiates the collective signing of a collective "forward- 325 pointer" attesting that the new collective public key is the one and 326 only valid successor to the old group's public key. Finally, once 327 this collectively signed forward-pointer is announced, all witness 328 nodes in the new and old group securely erase the private keys 329 representing their portions of the old collective public key. 331 Through these collectively signed forward-pointers, clients with old 332 software (containing old roots of trust) can "chain forward" from the 333 last collective witness group they know to the latest one by 334 retrieving and following a few such links. Provided witness groups 335 do not change too often (e.g., once a year), clients will not need 336 not follow too many such forward-pointers unless they are so out-of- 337 date that the security of their software and crypto is likely suspect 338 anyway. 340 3. Security Considerations 342 This draft contains nothing but security considerations. 344 4. References 346 4.1. Normative References 348 [COSI] Syta, E., Tamas, I., Visher, D., Wolinsky, D., and B. 349 Ford, "Decentralizing Authorities into Scalable Strongest- 350 Link Cothorities", March 2015, 351 . 353 4.2. Informative References 355 [MULTISIG] 356 Micali, S., Ohta, K., and L. Reyzin, "Accountable-Subgroup 357 Multisignatures", ACM Conference on Computer and 358 Communications Security 2001, August 2001, 359 . 361 Author's Address 363 Bryan Ford 364 EPFL 365 BC 210, Station 14 366 Lausanne CH-1015 367 Switzerland 369 Phone: +41 21 693 28 73 370 Email: bryan.ford@epfl.ch