idnits 2.17.1 draft-ietf-tokbind-protocol-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC5246]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 27, 2015) is 3318 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTPSTB' ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-06) exists of draft-ietf-tls-session-hash-04 Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force A. Popov, Ed. 3 Internet-Draft M. Nystroem 4 Intended status: Standards Track Microsoft Corp. 5 Expires: September 28, 2015 D. Balfanz 6 A. Langley 7 Google Inc. 8 March 27, 2015 10 The Token Binding Protocol Version 1.0 11 draft-ietf-tokbind-protocol-00 13 Abstract 15 This document specifies Version 1.0 of the Token Binding protocol. 16 The Token Binding protocol allows client/server applications to 17 create long-lived, uniquely identifiable TLS [RFC5246] bindings 18 spanning multiple TLS sessions and connections. Applications are 19 then enabled to cryptographically bind security tokens to the TLS 20 layer, preventing token export and replay attacks. To protect 21 privacy, the TLS Token Binding identifiers are only transmitted 22 encrypted and can be reset by the user at any time. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 28, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Token Binding Protocol Overview . . . . . . . . . . . . . . . 3 61 3. Negotiating the Token Binding Protocol and Key Parameters . . 4 62 4. Token Binding Protocol Message . . . . . . . . . . . . . . . 5 63 5. Establishing a TLS Token Binding . . . . . . . . . . . . . . 7 64 6. TLS Token Binding ID Format . . . . . . . . . . . . . . . . . 7 65 7. Security Token Validation . . . . . . . . . . . . . . . . . . 8 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 9.1. Security Token Replay . . . . . . . . . . . . . . . . . . 11 69 9.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 11 70 9.3. Privacy Considerations . . . . . . . . . . . . . . . . . 11 71 9.4. Triple Handshake Vulnerability in TLS . . . . . . . . . . 11 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 74 10.2. Informative References . . . . . . . . . . . . . . . . . 12 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 77 1. Introduction 79 Web services generate various security tokens (e.g. HTTP cookies, 80 OAuth tokens) for web applications to access protected resources. 81 Any party in possession of such token gains access to the protected 82 resource. Attackers export bearer tokens from the user's machine, 83 present them to web services, and impersonate authenticated users. 84 The idea of Token Binding is to prevent such attacks by 85 cryptographically binding security tokens to the TLS layer. 87 A TLS Token Binding is established by the user agent generating a 88 private-public key pair (possibly within a secure hardware module, 89 such as TPM) per target server, and proving possession of the private 90 key on every TLS connection to the target server. The proof of 91 possession involves signing the tls_unique value [RFC5929] for the 92 TLS connection with the private key. Such TLS Token Binding is 93 identified by the corresponding public key. TLS Token Bindings are 94 long-lived, i.e. they encompass multiple TLS connections and TLS 95 sessions between a given client and server. To protect privacy, TLS 96 Token Binding identifiers are never transmitted in clear text and can 97 be reset by the user at any time, e.g. when clearing browser cookies. 99 When issuing a security token to a client that supports TLS Token 100 Binding, a server includes the client's TLS Token Binding ID in the 101 token. Later on, when a client presents a security token containing 102 a TLS Token Binding ID, the server makes sure the ID in the token 103 matches the ID of the TLS Token Binding established with the client. 104 In the case of a mismatch, the server discards the token. 106 In order to successfully export and replay a bound security token, 107 the attacker needs to also be able to export the client's private 108 key, which is hard to do in the case of the key generated in a secure 109 hardware module. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 2. Token Binding Protocol Overview 119 The client and server use ALPN protocol IDs [RFC7301] to negotiate 120 the use of the Token Binding protocol, in addition to the actual 121 application protocol such as HTTP/1.1 [RFC2616] or HTTP/2 122 [I-D.ietf-httpbis-http2]. ALPN IDs are also used to negotiate the 123 parameters (signature algorithm, length) of the Token Binding key. 124 This negotiation does not require TLS protocol changes or additional 125 round-trips. 127 The "IANA Considerations" section of this document defines an initial 128 set of ALPN protocol IDs that allow the use of the Token Binding 129 protocol with HTTP/1.1 and HTTP/2. The initial set of supported key 130 parameters includes ECDSA with NIST P256 curve and 2048-bit RSA. New 131 ALPN protocol IDs can be defined in the future to support Token 132 Binding usage with other application protocols and key parameters. 134 The Token Binding protocol consists of one message sent by the client 135 to the server, proving possession of one or more client-generated 136 asymmetric keys. This message is only sent if the client and server 137 agree on the use of the Token Binding protocol and the key 138 parameters. The Token Binding message is sent with the application 139 protocol data in TLS application_data records. 141 A server receiving the Token Binding message verifies that the key 142 parameters in the message match the Token Binding parameters 143 negotiated via ALPN, and then validates the signatures contained in 144 the Token Binding message. If either of these checks fails, the 145 server terminates the connection, otherwise the TLS Token Binding is 146 successfully established with the ID contained in the Token Binding 147 message. 149 When a server supporting the Token Binding protocol receives a bound 150 token, the server compares the TLS Token Binding ID in the security 151 token with the TLS Token Binding ID established with the client. If 152 the bound token came from a TLS connection without a Token Binding, 153 or if the IDs don't match, the token is discarded. 155 This document describes the negotiation of the Token Binding protocol 156 and key parameters, the format of the Token Binding protocol message, 157 the process of establishing a TLS Token Binding, the format of the 158 Token Binding ID, and the process of validating a security token. 159 Token Binding over HTTP [HTTPSTB] explains how the Token Binding 160 message is encapsulated within application protocol messages. 161 [HTTPSTB] also describes Token Binding between multiple communicating 162 parties: User Agent, Identity Provider and Relying Party. 164 3. Negotiating the Token Binding Protocol and Key Parameters 166 The Token Binding protocol is used within TLS connections, in 167 combination with an application protocol such as HTTP/1.1 or HTTP/2. 168 The "IANA Considerations" section of this document defines a set of 169 ALPN protocol IDs that combine application protocol and token binding 170 key parameters: 172 o "h2_tb_p256" indicates support for HTTP/2 with Token Binding using 173 ECDSA key and NIST P256 curve; 175 o "h2_tb_rsa2048" indicates support for HTTP/2 with Token Binding 176 using 2048-bit RSA key; 178 o "http/1.1_tb_p256" indicates support for HTTP/1.1 with Token 179 Binding using ECDSA key and NIST P256 curve; 181 o "http/1.1_tb_rsa2048" indicates support for HTTP/1.1 with Token 182 Binding using 2048-bit RSA key. 184 The client advertises support of the Token Binding protocol by 185 sending some of these IDs in the ALPN extension in the ClientHello. 186 Application protocol IDs without Token Binding, such as "http/1.1" 187 and "h2", can also be included for compatibility with the servers 188 that do not support the Token Binding protocol. 190 The server indicates support of the Token Binding protocol by sending 191 one of the above IDs in the ALPN extension in the ServerHello. The 192 server implements the protocol selection logic as described in 193 section 3.2 "Protocol Selection" of [RFC7301], taking into account 194 the application protocols and key parameters supported by the server. 196 4. Token Binding Protocol Message 198 The Token Binding message is sent by the client and proves possession 199 of one or more private keys held by the client. This message MUST be 200 sent if the client and server successfully negotiated the use of the 201 Token Binding protocol via ALPN, and MUST NOT be sent otherwise. 202 This message MUST be sent in the client's first application protocol 203 message. This message MAY also be sent in subsequent application 204 protocol messages, proving possession of other keys by the same 205 client, to facilitate token binding between more than two 206 communicating parties. Token Binding over HTTP [HTTPSTB] specifies 207 the encapsulation of the Token Binding message in the application 208 protocol messages, and the scenarios involving more than two 209 communicating parties. The Token Binding message format is defined 210 using TLS specification language, and reuses existing TLS structures 211 and IANA registrations where possible: 213 enum { 214 sha256(4), (255) 215 } HashAlgorithm; 217 enum { 218 rsa(1), ecdsap256(3), (255) 219 } SignatureAlgorithm; 221 struct { 222 HashAlgorithm hash; 223 SignatureAlgorithm signature; 224 } SignatureAndHashAlgorithm; 226 struct { 227 opaque modulus<1..2^16-1>; 228 opaque publicexponent<1..2^8-1>; 229 } RSAPublicKey; 231 enum { 232 secp256r1 (23), (0xFFFF) 233 } NamedCurve; 235 struct { 236 opaque point <1..2^8-1>; 237 } ECPoint; 238 struct { 239 NamedCurve namedcurve; 240 ECPoint point; // Uncompressed format 241 } ECDSAParams; 243 enum { 244 provided_token_binding(0), referred_token_binding(1), (255) 245 } TokenBindingType; 247 struct { 248 TokenBindingType tokenbinding_type; 249 SignatureAndHashAlgorithm algorithm; 250 select (algorithm.signature) { 251 case rsa: RSAPublicKey rsapubkey; 252 case ecdsa: ECDSAParams ecdsaparams; 253 } 254 } TokenBindingID; 256 enum { 257 (255) // No initial ExtensionType registrations 258 } ExtensionType; 260 struct { 261 ExtensionType extension_type; 262 opaque extension_data<0..2^16-1>; 263 } Extension; 265 struct { 266 TokenBindingID tokenbindingid; 267 opaque signature<0..2^16-1>;// Signature over hashed ("token binding", tls_unique) 268 Extension extensions<0..2^16-1>; 269 } TokenBinding; 271 struct { 272 TokenBinding tokenbindings<0..2^16-1>; 273 } TokenBindingMessage; 275 The Token Binding message consists of a series of TokenBinding 276 structures containing the TokenBindingID, a signature over the hash 277 of the NUL-terminated, ASCII label ("token binding") and the 278 tls_unique, optionally followed by Extension structures. An 279 implementation MUST ignore any unknown extensions. Initially, no 280 extension types are defined. At least one TokenBinding MUST be 281 included in the Token Binding message. The signature algorithm and 282 key length used in the TokenBinding MUST match the parameters 283 negotiated via ALPN. The client SHOULD generate and store Token 284 Binding keys in a secure manner that prevents key export. In order 285 to prevent cooperating servers from linking user identities, 286 different keys SHOULD be used by the client for connections to 287 different servers, according to the token scoping rules of the 288 application protocol. 290 5. Establishing a TLS Token Binding 292 Triple handshake vulnerability in the TLS protocol affects the 293 security of the Token Binding protocol, as described in the "Security 294 Considerations" section below. Therefore, the server MUST NOT 295 negotiate the use of the Token Binding protocol unless the server 296 also negotiates Extended Master Secret TLS extension 297 [I-D.ietf-tls-session-hash]. 299 The server MUST terminate the connection if the use of the Token 300 Binding protocol has been successfully negotiated via ALPN within the 301 TLS handshake, but the client's first application message does not 302 contain the Token Binding message. The server MUST terminate the 303 connection if the use of the Token Binding protocol was not 304 negotiated, but the client sends the Token Binding message. 306 If the Token Binding type is "provided_token_binding", the server 307 MUST verify that the signature algorithm (including elliptic curve in 308 the case of ECDSA) and key length in the Token Binding message match 309 those negotiated via ALPN. In the case of a mismatch, the server 310 MUST terminate the connection. As described in [HTTPSTB], Token 311 Bindings of type "referred_token_binding" may have different key 312 parameters than those negotiated via ALPN. 314 If the Token Binding message does not contain at least one 315 TokenBinding structure, or the signature contained in a TokenBinding 316 structure is invalid, the server MUST terminate the connection. 317 Otherwise, the TLS Token Binding is successfully established and its 318 ID can be provided to the application for security token validation. 320 6. TLS Token Binding ID Format 321 The ID of the TLS Token Binding established as a result of Token 322 Binding message processing is a binary representation of the 323 following structure: 325 struct { 326 TokenBindingType tokenbinding_type; 327 SignatureAndHashAlgorithm algorithm; 328 select (algorithm.signature) { 329 case rsa: RSAPublicKey rsapubkey; 330 case ecdsa: ECDSAParams ecdsaparams; 331 } 332 } TokenBindingID; 334 TokenBindingID includes the type of the token binding and the key 335 parameters negotiated via ALPN. This document defines two token 336 binding types: provided_token_binding used to establish a Token 337 Binding when connecting to a server, and referred_token_binding used 338 when requesting tokens to be presented to a different server. Token 339 Binding over HTTP [HTTPSTB] describes Token Binding between multiple 340 communicating parties: User Agent, Identity Provider and Relying 341 Party. TLS Token Binding ID can be obtained from the TokenBinding 342 structure described in the "Token Binding Protocol Message" section 343 of this document by discarding the signature and extensions. TLS 344 Token Binding ID will be available at the application layer and used 345 by the server to generate and verify bound tokens. 347 7. Security Token Validation 349 Security tokens can be bound to the TLS layer either by embedding the 350 Token Binding ID in the token, or by maintaining a database mapping 351 tokens to Token Binding IDs. The specific method of generating bound 352 security tokens is application-defined and beyond the scope of this 353 document. 355 Upon receipt of a security token, the server attempts to retrieve TLS 356 Token Binding ID information from the token and from the TLS 357 connection with the client. Application-provided policy determines 358 whether to honor non-bound (bearer) tokens. If the token is bound 359 and a TLS Token Binding has not been established for the client 360 connection, the server MUST discard the token. If the TLS Token 361 Binding ID for the token does not match the TLS Token Binding ID 362 established for the client connection, the server MUST discard the 363 token. 365 8. IANA Considerations 367 This document establishes a registry for Token Binding type 368 identifiers entitled "Token Binding Types" under the "Token Binding 369 Protocol" heading. 371 Entries in this registry require the following fields: 373 o Value: The octet value that identifies the Token Binding type 374 (0-255). 376 o Description: The description of the Token Binding type. 378 o Specification: A reference to a specification that defines the 379 Token Binding type. 381 This registry operates under the "Expert Review" policy as defined in 382 [RFC5226]. The designated expert is advised to encourage the 383 inclusion of a reference to a permanent and readily available 384 specification that enables the creation of interoperable 385 implementations using the identified Token Binding type. 387 An initial set of registrations for this registry follows: 389 Value: 0 391 Description: provided_token_binding 393 Specification: this document 395 Value: 1 397 Description: referred_token_binding 399 Specification: this document 401 This document establishes a registry for Token Binding extensions 402 entitled "Token Binding Extensions" under the "Token Binding 403 Protocol" heading. 405 Entries in this registry require the following fields: 407 o Value: The octet value that identifies the Token Binding extension 408 (0-255). 410 o Description: The description of the Token Binding extension. 412 o Specification: A reference to a specification that defines the 413 Token Binding extension. 415 This registry operates under the "Expert Review" policy as defined in 416 [RFC5226]. The designated expert is advised to encourage the 417 inclusion of a reference to a permanent and readily available 418 specification that enables the creation of interoperable 419 implementations using the identified Token Binding extension. This 420 document creates no initial registrations in the "Token Binding 421 Extensions" registry. 423 This document creates the following registrations for the 424 identification of the Token Binding protocol in the "Application 425 Layer Protocol Negotiation (ALPN) Protocol IDs" registry originally 426 created in [RFC7301]: 428 Protocol: HTTP/2 with Token Binding using ECDSA key and NIST P256 429 curve 431 Identification Sequence: 0x68 0x32 0x5f 0x74 0x62 0x5f 0x70 0x32 432 0x35 0x36 ("h2_tb_p256") 434 Specification: this document 436 Protocol: HTTP/2 with Token Binding using 2048-bit RSA key 438 Identification Sequence: 0x68 0x32 0x5f 0x74 0x62 0x5f 0x72 0x73 439 0x61 0x32 0x30 0x34 0x38 ("h2_tb_rsa2048") 441 Specification: this document 443 Protocol: HTTP/1.1 with Token Binding using ECDSA key and NIST 444 P256 curve 446 Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 447 0x5f 0x74 0x62 0x5f 0x70 0x32 0x35 0x36 ("http/1.1_tb_p256") 449 Specification: this document 451 Protocol: HTTP/1.1 with Token Binding using 2048-bit RSA key 453 Identification Sequence: 0x68 0x74 0x74 0x70 0x2f 0x31 0x2e 0x31 454 0x5f 0x74 0x62 0x5f 0x72 0x73 0x61 0x32 0x30 0x34 0x38 455 ("http/1.1_tb_rsa2048") 457 Specification: this document 459 This document uses "TLS SignatureAlgorithm" and "TLS HashAlgorithm" 460 registries originally created in [RFC5246], and "TLS NamedCurve" 461 registry originally created in [RFC4492]. This document creates no 462 new registrations in these registries. 464 9. Security Considerations 466 9.1. Security Token Replay 468 The goal of the Token Binding protocol is to prevent attackers from 469 exporting and replaying security tokens, thereby impersonating 470 legitimate users and gaining access to protected resources. Bound 471 tokens can still be replayed by the malware present in the User 472 Agent. In order to export the token to another machine and 473 successfully replay it, the attacker also needs to export the 474 corresponding private key. Token Binding private keys are therefore 475 high-value assets and SHOULD be strongly protected, ideally by 476 generating them in a hardware security module that prevents key 477 export. 479 9.2. Downgrade Attacks 481 The Token Binding protocol is only used when negotiated via ALPN 482 within the TLS handshake. TLS prevents active attackers from 483 modifying the messages of the TLS handshake, therefore it is not 484 possible for the attacker to remove or modify the ALPN IDs used to 485 negotiate the Token Binding protocol and key parameters. The 486 signature algorithm and key length used in the TokenBinding of type 487 "provided_token_binding" MUST match the parameters negotiated via 488 ALPN. 490 9.3. Privacy Considerations 492 The Token Binding protocol uses persistent, long-lived TLS Token 493 Binding IDs. To protect privacy, TLS Token Binding IDs are never 494 transmitted in clear text and can be reset by the user at any time, 495 e.g. when clearing browser cookies. In order to prevent cooperating 496 servers from linking user identities, different keys SHOULD be used 497 by the client for connections to different servers, according to the 498 token scoping rules of the application protocol. 500 9.4. Triple Handshake Vulnerability in TLS 502 The Token Binding protocol relies on the tls_unique value to 503 associate a TLS connection with a TLS Token Binding. The triple 504 handshake attack [TRIPLE-HS] is a known TLS protocol vulnerability 505 allowing the attacker to synchronize tls_unique values between TLS 506 connections. The attacker can then successfully replay bound tokens. 508 For this reason, the Token Binding protocol MUST NOT be negotiated 509 unless the Extended Master Secret TLS extension 510 [I-D.ietf-tls-session-hash] has also been negotiated. 512 10. References 514 10.1. Normative References 516 [HTTPSTB] Balfanz, D., Langley, A., Popov, A., and M. Nystroem, 517 "Token Binding over HTTP", 2014. 519 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 520 Requirement Levels", BCP 14, RFC 2119, March 1997. 522 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 523 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 524 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 526 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 527 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 528 for Transport Layer Security (TLS)", RFC 4492, May 2006. 530 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 531 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 532 May 2008. 534 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 535 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 537 [RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings 538 for TLS", RFC 5929, July 2010. 540 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 541 "Transport Layer Security (TLS) Application-Layer Protocol 542 Negotiation Extension", RFC 7301, July 2014. 544 10.2. Informative References 546 [I-D.ietf-httpbis-http2] 547 Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer 548 Protocol version 2", draft-ietf-httpbis-http2-17 (work in 549 progress), February 2015. 551 [I-D.ietf-tls-session-hash] 552 Bhargavan, K., Delignat-Lavaud, A., Pironti, A., Langley, 553 A., and M. Ray, "Transport Layer Security (TLS) Session 554 Hash and Extended Master Secret Extension", draft-ietf- 555 tls-session-hash-04 (work in progress), March 2015. 557 [TRIPLE-HS] 558 Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, 559 A., and P. Strub, "Triple Handshakes and Cookie Cutters: 560 Breaking and Fixing Authentication over TLS. IEEE 561 Symposium on Security and Privacy", 2014. 563 Authors' Addresses 565 Andrei Popov (editor) 566 Microsoft Corp. 567 USA 569 Email: andreipo@microsoft.com 571 Magnus Nystroem 572 Microsoft Corp. 573 USA 575 Email: mnystrom@microsoft.com 577 Dirk Balfanz 578 Google Inc. 579 USA 581 Email: balfanz@google.com 583 Adam Langley 584 Google Inc. 585 USA 587 Email: agl@google.com