idnits 2.17.1 draft-perrin-tls-tack-01.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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 230 has weird spacing: '... Tack tack...' -- The document date (September 26, 2012) is 4230 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '64' on line 226 -- Looks like a reference, but probably isn't: '32' on line 225 -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-3' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6090 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group M. Marlinspike 3 Internet-Draft T. Perrin, Ed. 4 Intended status: Standards Track September 26, 2012 5 Expires: March 30, 2013 7 Trust Assertions for Certificate Keys 8 draft-perrin-tls-tack-01.txt 10 Abstract 12 This document defines TACK, a TLS Extension that enables a TLS server 13 to assert the authenticity of its public key. A "tack" contains a 14 "TACK key" which is used to sign the public key from the TLS server's 15 certificate. Hostnames can be "pinned" to a TACK key. TLS 16 connections to a pinned hostname require the server to present a tack 17 containing the pinned key and a corresponding signature over the TLS 18 server's public key. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 30, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3.1. Tack life cycle . . . . . . . . . . . . . . . . . . . . . 5 58 3.2. Pin life cycle . . . . . . . . . . . . . . . . . . . . . . 6 59 4. TACK Extension . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Definition of TackExtension . . . . . . . . . . . . . . . 7 61 4.2. Explanation of TackExtension fields . . . . . . . . . . . 8 62 4.2.1. Tack fields . . . . . . . . . . . . . . . . . . . . . 8 63 4.2.2. TackExtension fields . . . . . . . . . . . . . . . . . 8 64 5. Client processing . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. TACK pins . . . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. High-level client processing . . . . . . . . . . . . . . . 9 67 5.3. Client processing details . . . . . . . . . . . . . . . . 10 68 5.3.1. Check whether the TLS handshake is well-formed . . . . 10 69 5.3.2. Check tack generations and update min_generations . . 10 70 5.3.3. Determine the store's status . . . . . . . . . . . . . 11 71 5.3.4. Pin activation (optional) . . . . . . . . . . . . . . 11 72 6. Application protocols and TACK . . . . . . . . . . . . . . . . 13 73 6.1. Pin scope . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 13 75 6.3. Certificate verification . . . . . . . . . . . . . . . . . 13 76 7. Fingerprints . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 8. Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 8.1. For server operators . . . . . . . . . . . . . . . . . . . 15 79 8.2. For client implementers . . . . . . . . . . . . . . . . . 16 80 9. Security considerations . . . . . . . . . . . . . . . . . . . 17 81 9.1. For server operators . . . . . . . . . . . . . . . . . . . 17 82 9.2. For client implementers . . . . . . . . . . . . . . . . . 17 83 9.3. Note on algorithm agility . . . . . . . . . . . . . . . . 18 84 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 85 10.1. New entry for the TLS ExtensionType Registry . . . . . . . 19 86 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 87 12. Normative references . . . . . . . . . . . . . . . . . . . . . 21 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 90 1. Introduction 92 Traditionally, a TLS client verifies a TLS server's public key using 93 a certificate chain issued by some public CA. "Pinning" is a way for 94 clients to obtain increased certainty in server public keys. Clients 95 that employ pinning check for some constant "pinned" element of the 96 TLS connection when contacting a particular TLS host. 98 Unfortunately, a number of problems arise when attempting to pin 99 certificate chains: the TLS servers at a given hostname may have 100 different certificate chains simultaneously deployed and may change 101 their chains at any time, the "more constant" elements of a chain 102 (the CAs) may not be trustworthy, and the client may be oblivious to 103 key compromise events which render the pinned data untrustworthy. 105 TACK addresses these problems by having the site sign its TLS server 106 public keys with a "TACK key". This enables clients to "pin" a 107 hostname to the TACK key without requiring sites to modify their 108 existing certificate chains, and without limiting a site's 109 flexibility to deploy different certificate chains on different 110 servers or change certificate chains at any time. Since TACK pins 111 are based on TACK keys (instead of CA keys), trust in CAs is not 112 required. Additionally, the TACK key may be used to revoke 113 compromised TLS private keys, and TACK key rollovers may be performed 114 to recover from suspect or compromised TACK keys. 116 If requested, a compliant server will send a TLS Extension containing 117 its "tack". Inside the tack is a public key and signature. Once a 118 client has seen the same (hostname, TACK public key) pair multiple 119 times, the client will "activate" a pin between the hostname and TACK 120 key for a period equal to the length of time the pair has been 121 observed for. This "pin activation" algorithm limits the impact of 122 bad pins resulting from transient network attacks or operator error. 124 TACK pins are easily shared between clients. For example, a TACK 125 client may scan the internet to discover TACK pins, then publish 126 these pins through some 3rd-party trust infrastructure for other 127 clients to rely upon. 129 2. Requirements notation 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 3. Overview 137 3.1. Tack life cycle 139 A server operator using TACK may perform several processes: 141 Selection of a TACK key: The server operator first chooses the ECDSA 142 signing key to use for a set of hostnames. It is safest to use a 143 different signing key for each hostname, though a signing key may 144 be reused for closely-related hostnames (such as aliases for the 145 same host, or hosts sharing the same TLS key). 147 Creating initial tacks under a TACK key: The TACK private key is 148 then used to sign the TLS public keys for all servers associated 149 with those hostnames. The TACK public key and signature are 150 combined with some metadata into each server's "tack". 152 Deploying initial tacks: For each hostname, tacks are deployed to 153 TLS servers in a two-stage process. First, each TLS server 154 associated with the hostname is given a tack. Once this is 155 completed, the tacks are activated by setting the "activation 156 flag" on each server. 158 Creating new tacks under a TACK key: A tack needs to be replaced 159 whenever a server changes its TLS public key, or when the tack 160 expires. Tacks may also need to be replaced with later-generation 161 tacks if the TACK key's "min_generation" is updated (see next). 163 Revoking old tacks: If a TLS private key is compromised, the tacks 164 signing this key can be revoked by publishing a new tack 165 containing a higher "min_generation". 167 Deactivating tacks: If a server operator wishes to stop deploying 168 tacks, all tacks for a hostname can be deactivated via the 169 activation flag, allowing the server to remove the tacks within 30 170 days (at most). 172 Rollover: If a server operator wishes to change the TACK key a 173 hostname is pinned to, the server can publish a new tack alongside 174 the old one. This lets clients activate pins for the new TACK key 175 prior to the server deactivating the older pins. 177 3.2. Pin life cycle 179 A TACK pin associates a hostname and a TACK key. Pins are grouped 180 into "pin stores". A client may populate its pin stores by either 181 performing "pin activation" directly, or by querying some other 182 party. For example, a client application may have a store for pin 183 activation as well as a store whose contents are periodically fetched 184 from a server. 186 Whenever a client performing "pin activation" sees a hostname and 187 TACK key combination not represented in the "pin activation" pin 188 store, an inactive pin is created. Every subsequent time the client 189 sees the same pin, the pin is "activated" for a period equal to the 190 timespan between the first time the pin was seen and the most recent 191 time, up to a maximum period of 30 days. 193 A pin store may contain up to two pins per hostname. This allows for 194 "pin rollover", where a server securely transitions from one pin to 195 another. If both pins are simultaneously active, then the server 196 must satisfy both of them by presenting a pair of tacks. 198 In addition to creating and activating pins, a TLS connection can 199 alter client pin stores by publishing new "min_generation" values in 200 a tack. Each pin stores the highest "min_generation" value it has 201 seen from the pinned TACK key, and rejects tacks from earlier 202 generations. 204 4. TACK Extension 206 4.1. Definition of TackExtension 208 A new TLS ExtensionType ("tack") is defined and MAY be included by a 209 TLS client in the ClientHello message defined in [RFC5246]. 211 enum {tack(TBD), (65535)} ExtensionType; 213 The "extension_data" field of this ClientHello extension SHALL be 214 empty. A TLS server which is not resuming a TLS session MAY respond 215 with an extension of type "tack" in the ServerHello. The 216 "extension_data" field of this ServerHello extension SHALL contain a 217 "TackExtension", as defined below using the TLS presentation language 218 from [RFC5246]. 220 struct { 221 opaque public_key[64]; 222 uint8 min_generation; 223 uint8 generation; 224 uint32 expiration; 225 opaque target_hash[32]; 226 opaque signature[64]; 227 } Tack; /* 166 bytes */ 229 struct { 230 Tack tacks<166...332> /* 1 or 2 Tacks */ 231 uint8 activation_flags; /* 0...3 */ 232 } TackExtension; 234 4.2. Explanation of TackExtension fields 236 4.2.1. Tack fields 238 public_key: This field specifies the tack's public key. The field 239 contains a pair of integers (x, y) representing a point on the 240 elliptic curve P-256 defined in [FIPS186-3]. Each integer is 241 encoded as a 32-byte octet string using the Integer-to-Octet- 242 String algorithm from [RFC6090], and these strings are 243 concatenated with the x value first. (NOTE: This is equivalent to 244 an uncompressed subjectPublicKey from [RFC5480], except that the 245 initial 0x04 byte is omitted). 247 min_generation: This field publishes a min_generation value. 249 generation: This field assigns each tack a generation. Generations 250 less than a published min_generation are considered revoked. 252 expiration: This field specifies a time after which the tack is 253 considered expired. The time is encoded as the number of minutes, 254 excluding leap seconds, after midnight UTC, January 1 1970. 256 target_hash: This field is a hash of the TLS server's 257 SubjectPublicKeyInfo [RFC5280] using the SHA256 algorithm from 258 [FIPS180-2]. The SubjectPublicKeyInfo is typically conveyed as 259 part of the server's X.509 certificate. 261 signature: This field is an ECDSA signature by the tack's public key 262 over the 8 byte ASCII string "tack_sig" followed by the contents 263 of the tack prior to the "signature" field (i.e. the preceding 102 264 bytes). The field contains a pair of integers (r, s) representing 265 an ECDSA signature as defined in [FIPS186-3], using curve P-256 266 and SHA256. Each integer is encoded as a 32-byte octet string 267 using the Integer-to-Octet-String algorithm from [RFC6090], and 268 these strings are concatenated with the r value first. 270 4.2.2. TackExtension fields 272 tacks: This field provides the server's tack(s). It SHALL contain 1 273 or 2 tacks. 275 activation_flags: This field contains "activation flags" for the 276 extension's tacks. If the low order bit is set, the first tack is 277 considered active. If the next lowest bit is set, the second tack 278 is considered active. An active tack MAY be used by the pin 279 activation algorithm in Section 5.3.4 to create, activate, and 280 extend the activation of TACK pins. 282 5. Client processing 284 5.1. TACK pins 286 A client SHALL have a local store of pins, and MAY have multiple 287 stores. Each pin store consists of a map associating fully qualified 288 DNS hostnames with either one or two sets of the following values: 290 Initial time: A timestamp noting when this pin was created. 292 End time: A timestamp determining the pin's "active period". If set 293 to zero or a time in the past, the pin is "inactive". If set to a 294 future time, the pin is "active" until that time. 296 TACK public key (or hash): A public key or a cryptographically- 297 secure, second preimage-resistant hash of a public key. 299 Min_generation: A single byte used to detect revoked tacks. All 300 pins within a pin store sharing the same TACK public key SHALL 301 have the same min_generation. 303 A hostname along with the above values comprises a "TACK pin". Thus, 304 each store can hold up to two pins for a hostname (however, those two 305 pins MUST reference different public keys). A pin "matches" a tack 306 if they reference the same public key. A pin is "relevant" if its 307 hostname equals the TLS server's hostname. 309 5.2. High-level client processing 311 A TACK client SHALL send the "tack" extension defined previously, and 312 SHALL send the "server_name" extension from [RFC6066]. If not 313 resuming a session, the server MAY respond with a TackExtension. 314 Regardless of whether a TackExtension is returned, the client SHALL 315 perform the following steps prior to using the connection: 317 1. Check whether the TLS handshake is "well-formed". 319 2. For each pin store, do: 321 A. Check tack generations and update min_generations. 323 B. Determine the store's status. 325 C. Perform pin activation (optional). 327 These steps SHALL be performed in order. If there is any error, the 328 client SHALL send a fatal error alert and close the connection, 329 skipping the remaining steps (see Section 5.3 for details). 331 Based on step 2B, each store will report one of three statuses for 332 the connection: "accepted", "rejected", or "unpinned". A rejected 333 connection might indicate a network attack. If the connection is 334 rejected the client SHOULD send a fatal "access_denied" error alert 335 and close the connection. 337 A client MAY perform additional verification steps before using an 338 accepted or unpinned connection. See Section 6.3 for an example. 340 5.3. Client processing details 342 5.3.1. Check whether the TLS handshake is well-formed 344 A TLS handshake is "well-formed" if the following are true. Unless 345 otherwise specified, if any of the following are false a 346 "bad_certificate" fatal error alert SHALL be sent. 348 1. The handshake protocol negotiates a cryptographically secure 349 ciphersuite and finishes succesfully. 351 2. If a TackExtension is present then all length fields are correct, 352 "activation_flags" is <= 3, and the tacks are "well-formed" (see 353 below). 355 3. If there are two tacks, they have different "public_key" fields. 357 A tack is "well-formed" if: 359 1. "generation" is >= "min_generation". 361 2. "expiration" specifies a time in the future, otherwise the client 362 SHALL send a fatal "certificate_expired" error alert. 364 3. "target_hash" is a correct hash of the SubjectPublicKeyInfo. 366 4. "signature" is a correct ECDSA signature. 368 5.3.2. Check tack generations and update min_generations 370 If a tack has matching pins in the pin store and a generation less 371 than the stored min_generation, then that tack is revoked and the 372 client SHALL send a fatal "certificate_revoked" error alert. If a 373 tack has matching pins and a min_generation greater than the stored 374 min_generation, the stored value SHALL be set to the tack's value. 376 5.3.3. Determine the store's status 378 If there is a relevant active pin without a matching tack, then the 379 connection is "rejected". If the connection is not rejected and 380 there is a relevant active pin with a matching tack, then the 381 connection is "accepted". Otherwise, the connection is "unpinned". 383 5.3.4. Pin activation (optional) 385 The TLS connection MAY be used to create, delete, and activate pins. 386 This "pin activation algorithm" is optional; a client MAY rely on an 387 external source of pins. If the connection was "rejected" by the 388 previous processing step, then pin activation is skipped. 390 The first step in pin activation is to evaluate each relevant pin 391 (there may be one or two): 393 1. If a pin has no matching tack, its handling will depend on 394 whether the pin is active. If active, the connection will have 395 been rejected, skipping pin activation. If inactive, the pin 396 SHALL be deleted, since it is contradicted by the connection. 398 2. If a pin has a matching tack, its handling will depend on whether 399 the tack is active. If inactive, the pin is left unchanged. If 400 active, the pin SHALL have its "end time" set based on the 401 current, initial, and end times: 403 end = current + MIN(30 days, current - initial) 405 In sum: (1) deletes unmatched pins, provided they are inactive; and 406 (2) activates matched pins, provided the matching tack is active. 408 The remaining step in pin activation is to add new inactive pins for 409 any unmatched active tacks. Each new pin uses the server's hostname, 410 the tack's public key and min_generation (unless the store has a 411 higher min_generation for the public key), an "initial time" set to 412 the current time, and an "end time" of zero. 414 (Note that there are always sufficient empty "slots" in the pin store 415 for adding new pins without exceeding two pins per hostname. This is 416 because the number of matching pins equals the number of matching 417 tacks, so the number of empty pin slots equals the number of 418 unmatched tacks.) 420 The following tables summarize this behavior from the perspective of 421 a pin. You can follow the lifecycle of a single pin from "New 422 inactive pin" to "Delete pin". 424 Relevant pin is active: 426 +--------------------+----------------+--------------------------+ 427 | Pin matches a tack | Tack is active | Result | 428 +--------------------+----------------+--------------------------+ 429 | Yes | Yes | Extend activation period | 430 | | | | 431 | Yes | No | - | 432 | | | | 433 | No | - | (Connection rejected) | 434 +--------------------+----------------+--------------------------+ 436 Relevant pin is inactive: 438 +--------------------+----------------+--------------+ 439 | Pin matches a tack | Tack is active | Result | 440 +--------------------+----------------+--------------+ 441 | Yes | Yes | Activate pin | 442 | | | | 443 | Yes | No | - | 444 | | | | 445 | No | - | Delete pin | 446 +--------------------+----------------+--------------+ 448 Tack doesn't match any relevant pin: 450 +--------------------------+------------------+ 451 | Unmatched tack is active | Result | 452 +--------------------------+------------------+ 453 | Yes | New inactive pin | 454 | | | 455 | No | - | 456 +--------------------------+------------------+ 458 6. Application protocols and TACK 460 6.1. Pin scope 462 TACK pins are specific to a particular application protocol. In 463 other words, a pin for HTTPS at "example.com" implies nothing about 464 POP3 or SMTP at "example.com". 466 6.2. TLS negotiation 468 Some application protocols negotiate TLS as an optional feature (e.g. 469 SMTP using STARTTLS [RFC3207]). If such a server fails to negotiate 470 TLS and there are relevant active pins, then the connection is 471 rejected by the pin. If the server fails to negotiate TLS, then any 472 relevant, inactive pins SHALL be deleted. Note that these steps are 473 taken despite the absence of a TLS connection. 475 6.3. Certificate verification 477 A TACK client MAY choose to perform some form of certificate 478 verification in addition to TACK processing. When combining 479 certificate verification and TACK processing, the TACK processing 480 described in Section 5 SHALL be followed, with the exception that 481 TACK processing MAY be terminated early (or skipped) if some fatal 482 certificate error is discovered. 484 If TACK processing and certificate verification both complete without 485 a fatal error, the client SHALL apply some policy to decide whether 486 to accept the connection. The policy is up to the client. An 487 example policy would be to accept the connection only if it passes 488 certificate verification and is not rejected by a pin. 490 7. Fingerprints 492 A "key fingerprint" may be used to represent a TACK public key to 493 users in a form that is easy to compare and transcribe. A key 494 fingerprint consists of the first 25 characters from the base32 495 encoding of SHA256(public_key), split into 5 groups of 5 characters 496 separated by periods. Base32 encoding is as specified in [RFC4648], 497 except lowercase is used. Examples: 499 g5p5x.ov4vi.dgsjv.wxctt.c5iul 501 quxiz.kpldu.uuedc.j5znm.7mqst 503 e25zs.cth7k.tscmp.5hxdp.wf47j 505 8. Advice 507 8.1. For server operators 509 Key reuse: All servers that are pinned to a single TACK key are able 510 to impersonate each other, since clients will perceive their tacks 511 as equivalent. Thus, TACK keys SHOULD NOT be reused with 512 different hostnames unless these hostnames are closely related. 513 Examples where it would be safe to reuse a TACK key are hostnames 514 aliased to the same host, hosts sharing the same TLS key, or 515 hostnames for a group of near-identical servers. 517 Aliases: A TLS server may be referenced by multiple hostnames. 518 Clients may pin any of these hostnames. Server operators should 519 be careful when using DNS aliases that hostnames are not pinned 520 inadvertently. 522 Generations: To revoke older generations of tacks, the server 523 operator SHOULD first provide all servers with a new generation of 524 tacks, and only then provide servers with new tacks containing the 525 new min_generation. Otherwise, a client may receive a 526 min_generation update from one server but then try to contact an 527 older-generation server which has not yet been updated. 529 Tack expiration: When TACK is used in conjunction with certificates 530 it is recommended to set the tack expiration equal to the end- 531 entity certificate expiration plus 30 days, allowing the tack and 532 certificate to both be replaced at the same time. The extra 30 533 days ensures there is enough time to employ "pin deactivation" 534 (see below) if the TACK private key is lost. Alternatively, 535 short-lived tacks may be used so that a compromised TLS private 536 key has limited value to an attacker. 538 Tack/pin activation: Tacks should only be activated once all TLS 539 servers sharing the same hostname have a tack. Otherwise, a 540 client may activate a pin by contacting one server, then contact a 541 different server at the same hostname that does not yet have a 542 tack. 544 Tack/pin deactivation: If all servers at a hostname deactivate their 545 tacks (by clearing the activation flags), all existing pins for 546 the hostname will eventually become inactive. The tacks can be 547 removed after a time interval equal to the maximum active period 548 of any affected pins (30 days at most). 550 Pin rollover: When performing a rollover, the old and new tacks 551 SHOULD be published simultaneously for at least 60 days. This 552 ensures that a pin activation client who is contacting the server 553 at least once every 30 days will not have the length of its 554 activation periods affected by the transition. Example rollover 555 process: Add new tacks; activate new tacks; wait 30+ days; 556 deactivate old tacks; wait 30+ days; remove old tacks. 558 8.2. For client implementers 560 Sharing pin information: It is possible for a client to maintain a 561 pin store based entirely on its own TLS connections. However, 562 such a client runs the risk of creating incorrect pins, failing to 563 keep its pins active, or failing to receive min_generation 564 updates. Clients are advised to make use of 3rd-party trust 565 infrastructure so that pin data can be aggregated and shared. 566 This will require additional protocols outside the scope of this 567 document. 569 Clock synchronization: A client SHOULD take measures to prevent 570 tacks from being erroneously rejected as expired due to an 571 inaccurate client clock. Such methods MAY include using time 572 synchronization protocols such as NTP [RFC5905], or accepting 573 seemingly-expired tacks as "well-formed" if they expired less than 574 T minutes ago, where T is a "tolerance bound" set to the client's 575 maximum expected clock error. 577 9. Security considerations 579 9.1. For server operators 581 All servers pinned to the same TACK key can impersonate each other 582 (see Section 8.1). Think carefully about this risk if using the same 583 TACK key for multiple hostnames. 585 Make backup copies of the TACK private key and keep all copies in 586 secure locations where they can't be compromised. 588 A TACK private key MUST NOT be used to perform any non-TACK 589 cryptographic operations. For example, using a TACK key for email 590 encryption, code-signing, or any other purpose MUST NOT be done. 592 HTTP cookies [RFC6265] set by a pinned host can be stolen by a 593 network attacker who can forge web and DNS responses so as to cause a 594 client to send the cookies to a phony subdomain of the pinned host. 595 To prevent this, TACK HTTPS Servers SHOULD set the "secure" attribute 596 and omit the "domain" attribute on all security-sensitive cookies, 597 such as session cookies. These settings tell the browser that the 598 cookie should only be presented back to the originating host (not its 599 subdomains), and should only be sent over HTTPS (not HTTP) [RFC6265]. 601 9.2. For client implementers 603 A TACK pin store may contain private details of the client's 604 connection history. An attacker may be able to access this 605 information by hacking or stealing the client. Some information 606 about the client's connection history could also be gleaned by 607 observing whether the client accepts or rejects connections to phony 608 TLS servers without correct tacks. To mitigate these risks, a TACK 609 client SHOULD allow the user to edit or clear the pin store. 611 Aside from rejecting TLS connections, clients SHOULD NOT take any 612 actions which would reveal to a network observer the state of the 613 client's pin store, as this would allow an attacker to know in 614 advance whether a "man-in-the-middle" attack on a particular TLS 615 connection will succeed or be detected. 617 An attacker may attempt to flood a client with spurious tacks for 618 different hostnames, causing the client to delete old pins to make 619 space for new ones. To defend against this, clients SHOULD NOT 620 delete active pins to make space for new pins. Clients instead 621 SHOULD delete inactive pins. If there are no inactive pins to 622 delete, then the pin store is full and there is no space for new 623 pins. To select an inactive pin for deletion, the client SHOULD 624 delete the pin with the oldest "end time". 626 9.3. Note on algorithm agility 628 If the need arises for tacks using different cryptographic algorithms 629 (e.g., if SHA256 or ECDSA are shown to be weak), a "v2" version of 630 tacks could be defined, requiring assignment of a new TLS Extension 631 number. Tacks as defined in this document would then be known as 632 "v1" tacks. 634 10. IANA considerations 636 10.1. New entry for the TLS ExtensionType Registry 638 IANA is requested to add an entry to the existing TLS ExtensionType 639 registry, defined in [RFC5246], for "tack"(TBD) as defined in this 640 document. 642 11. Acknowledgements 644 Valuable feedback has been provided by Adam Langley, Chris Palmer, 645 Nate Lawson, and Joseph Bonneau. 647 12. Normative references 649 [FIPS180-2] 650 National Institute of Standards and Technology, "Secure 651 Hash Standard", FIPS PUB 180-2, August 2002, . 654 [FIPS186-3] 655 National Institute of Standards and Technology, "Digital 656 Signature Standard", FIPS PUB 186-3, June 2009, . 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 663 Transport Layer Security", RFC 3207, February 2002. 665 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 666 Encodings", RFC 4648, October 2006. 668 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 669 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 671 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 672 Housley, R., and W. Polk, "Internet X.509 Public Key 673 Infrastructure Certificate and Certificate Revocation List 674 (CRL) Profile", RFC 5280, May 2008. 676 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 677 "Elliptic Curve Cryptography Subject Public Key 678 Information", RFC 5480, March 2009. 680 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 681 Time Protocol Version 4: Protocol and Algorithms 682 Specification", RFC 5905, June 2010. 684 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 685 Extension Definitions", RFC 6066, January 2011. 687 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 688 Curve Cryptography Algorithms", RFC 6090, February 2011. 690 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 691 April 2011. 693 Authors' Addresses 695 Moxie Marlinspike 697 Trevor Perrin (editor) 699 Email: tack@trevp.net