idnits 2.17.1 draft-perrin-tls-tack-02.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 218 has weird spacing: '... Tack tack...' -- The document date (January 7, 2013) is 4125 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 214 -- Looks like a reference, but probably isn't: '32' on line 213 -- 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 January 7, 2013 5 Expires: July 11, 2013 7 Trust Assertions for Certificate Keys 8 draft-perrin-tls-tack-02.txt 10 Abstract 12 This document defines a TLS Extension that enables a TLS server to 13 support "pinning" to a self-chosen signing key. A client contacting 14 a pinned host will require the server to present a signature from the 15 signing key over the TLS server's public key. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 11, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 53 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Tack life cycle . . . . . . . . . . . . . . . . . . . . . 4 55 2.2. Pin life cycle . . . . . . . . . . . . . . . . . . . . . . 5 56 3. TACK Extension . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.1. Definition of TackExtension . . . . . . . . . . . . . . . 6 58 3.2. Explanation of TackExtension fields . . . . . . . . . . . 7 59 3.2.1. Tack fields . . . . . . . . . . . . . . . . . . . . . 7 60 3.2.2. TackExtension fields . . . . . . . . . . . . . . . . . 7 61 4. Client processing . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1. TACK pins . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2. High-level client processing . . . . . . . . . . . . . . . 8 64 4.3. Client processing details . . . . . . . . . . . . . . . . 9 65 4.3.1. Check whether the TLS handshake is valid . . . . . . . 9 66 4.3.2. Check tack generations and update min_generations . . 9 67 4.3.3. Determine the store's status . . . . . . . . . . . . . 10 68 4.3.4. Pin activation (optional) . . . . . . . . . . . . . . 10 69 5. Application protocols and TACK . . . . . . . . . . . . . . . . 12 70 5.1. Pin scope . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5.2. TLS negotiation . . . . . . . . . . . . . . . . . . . . . 12 72 5.3. Certificate verification . . . . . . . . . . . . . . . . . 12 73 6. Fingerprints . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. Advice . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. For server operators . . . . . . . . . . . . . . . . . . . 14 76 7.2. For client implementers . . . . . . . . . . . . . . . . . 15 77 8. Security considerations . . . . . . . . . . . . . . . . . . . 16 78 8.1. For server operators . . . . . . . . . . . . . . . . . . . 16 79 8.2. For client implementers . . . . . . . . . . . . . . . . . 16 80 8.3. Note on algorithm agility . . . . . . . . . . . . . . . . 17 81 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 82 9.1. New entry for the TLS ExtensionType Registry . . . . . . . 18 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 84 11. Normative references . . . . . . . . . . . . . . . . . . . . . 20 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 87 1. Introduction 89 Traditionally, a TLS client verifies a TLS server's public key using 90 a certificate chain issued by some public CA. "Pinning" is a way for 91 clients to obtain increased certainty in server public keys. Clients 92 that employ pinning check for some constant "pinned" element of the 93 TLS connection when contacting a particular TLS host. 95 TACK allows clients to pin to a server-chosen signing key, known as a 96 "TACK signing key" or "TSK", which signs the server's TLS keys. This 97 enables pinning without limiting a site's flexibility to deploy 98 different certificates and TLS keys on different servers or at 99 different times. Since pins are based on TSKs instead of CA keys, 100 trust in CAs is not required. Additionally, a TSK may be used to 101 revoke compromised TLS private keys, and a pair of "overlapping" TSKs 102 may be used to quickly introduce a new TSK if an older one has become 103 compromised or suspect. 105 If requested, a compliant server will send a TLS Extension containing 106 its "tack". Inside the tack is a TSK public key and signature. Once 107 a client has seen the same (hostname, TSK) pair multiple times, the 108 client will "activate" a pin between the hostname and TSK for a 109 period equal to the length of time the pair has been observed for. 110 This "pin activation" algorithm limits the impact of bad pins 111 resulting from transient network attacks or operator error. 113 TACK pins are easily shared between clients. For example, a TACK 114 client may scan the internet to discover TACK pins, then publish 115 these pins through some 3rd-party trust infrastructure for other 116 clients to rely upon. 118 1.1. Requirements notation 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 2. Overview 126 2.1. Tack life cycle 128 A server operator using TACK may perform several processes: 130 Selection of a TACK signing key (TSK): The server operator first 131 chooses the ECDSA signing key to use for a set of hostnames. It 132 is safest to use a different TSK for each hostname, though a TSK 133 may be reused for closely-related hostnames (such as aliases for 134 the same host, or hosts sharing the same TLS key). 136 Creating initial tacks under a TSK: The TSK private key is then used 137 to sign the TLS public keys for all servers associated with those 138 hostnames. The TSK public key and signature are combined with 139 some metadata into each server's "tack". 141 Deploying initial tacks: For each hostname, tacks are deployed to 142 TLS servers in a two-stage process. First, each TLS server 143 associated with the hostname is given a tack. Once this is 144 completed, the tacks are activated by setting the "activation 145 flag" on each server. 147 Creating new tacks under a TSK: A tack needs to be replaced whenever 148 a server changes its TLS public key, or when the tack expires. 149 Tacks may also need to be replaced with later-generation tacks if 150 the TSK's "min_generation" is updated (see next). 152 Revoking old tacks: If a TLS private key is compromised, the tacks 153 signing this key can be revoked by publishing a new tack 154 containing a higher "min_generation". 156 Deactivating tacks: If a server operator wishes to stop deploying 157 tacks, all tacks for a hostname can be deactivated via the 158 activation flag, allowing the server to remove the tacks within 30 159 days (at most). 161 Overlapping tacks: If a server operator wishes to change the TSK a 162 hostname is pinned to, the server can publish a new tack alongside 163 the old one. This lets clients activate pins for the new TSK 164 prior to the server deactivating the older pins. 166 2.2. Pin life cycle 168 A TACK pin associates a hostname and a TSK. Pins are grouped into 169 "pin stores". A client may populate its pin stores by either 170 performing "pin activation" directly, or by querying some other 171 party. For example, a client application may have a store for pin 172 activation as well as a store whose contents are periodically fetched 173 from a server. 175 Whenever a client performing "pin activation" sees a hostname and TSK 176 combination not represented in the "pin activation" pin store, an 177 inactive pin is created. Every subsequent time the client sees the 178 same pin, the pin is "activated" for a period equal to the timespan 179 between the first time the pin was seen and the most recent time, up 180 to a maximum period of 30 days. 182 A pin store may contain up to two pins per hostname. This allows for 183 overlapping pins when a server is securely transitioning from one pin 184 to another. If both pins are simultaneously active, then the server 185 must satisfy both of them by presenting a pair of tacks. 187 In addition to creating and activating pins, a TLS connection can 188 alter client pin stores by publishing new "min_generation" values in 189 a tack. Each pin stores the highest "min_generation" value it has 190 seen from the pinned TSK, and rejects tacks from earlier generations. 192 3. TACK Extension 194 3.1. Definition of TackExtension 196 A new TLS ExtensionType ("tack") is defined and MAY be included by a 197 TLS client in the ClientHello message defined in [RFC5246]. 199 enum {tack(TBD), (65535)} ExtensionType; 201 The "extension_data" field of this ClientHello extension SHALL be 202 empty. A TLS server which is not resuming a TLS session MAY respond 203 with an extension of type "tack" in the ServerHello. The 204 "extension_data" field of this ServerHello extension SHALL contain a 205 "TackExtension", as defined below using the TLS presentation language 206 from [RFC5246]. 208 struct { 209 opaque public_key[64]; 210 uint8 min_generation; 211 uint8 generation; 212 uint32 expiration; 213 opaque target_hash[32]; 214 opaque signature[64]; 215 } Tack; /* 166 bytes */ 217 struct { 218 Tack tacks<166...332> /* 1 or 2 tacks */ 219 uint8 activation_flags; 220 } TackExtension; /* 169 or 335 bytes */ 222 3.2. Explanation of TackExtension fields 224 3.2.1. Tack fields 226 public_key: Specifies the public key of the TSK that has signed this 227 tack. The field contains a pair of integers (x, y) representing a 228 point on the elliptic curve P-256 defined in [FIPS186-3]. Each 229 integer is encoded as a 32-byte octet string using the Integer-to- 230 Octet-String algorithm from [RFC6090], and these strings are 231 concatenated with the x value first. (NOTE: This is equivalent to 232 an uncompressed subjectPublicKey from [RFC5480], except that the 233 initial 0x04 byte is omitted). 235 min_generation: Publishes a min_generation for the tack's TSK. 237 generation: Assigns each tack a generation. Generations less than 238 the highest published min_generation for the tack's TSK are 239 considered revoked. 241 expiration: Specifies a time after which the tack is considered 242 expired. The time is encoded as the number of minutes, excluding 243 leap seconds, after midnight UTC, January 1 1970. 245 target_hash: A hash of the TLS server's SubjectPublicKeyInfo 246 [RFC5280] using the SHA256 algorithm from [FIPS180-2]. The 247 SubjectPublicKeyInfo is typically conveyed as part of the server's 248 X.509 end-entity certificate. 250 signature: An ECDSA signature by the tack's TSK over the 8 byte 251 ASCII string "tack_sig" followed by the contents of the tack prior 252 to the "signature" field (i.e. the preceding 102 bytes). The 253 field contains a pair of integers (r, s) representing an ECDSA 254 signature as defined in [FIPS186-3], using curve P-256 and SHA256. 255 Each integer is encoded as a 32-byte octet string using the 256 Integer-to-Octet-String algorithm from [RFC6090], and these 257 strings are concatenated with the r value first. 259 3.2.2. TackExtension fields 261 tacks: This field provides the server's tack(s). It SHALL contain 1 262 or 2 tacks. 264 activation_flags: This field contains "activation flags" for the 265 extension's tacks. If the low order bit is set, the first tack is 266 considered active. If the next lowest bit is set, the second tack 267 is considered active. All other bits are reserved for future use 268 and MUST be ignored by clients. 270 4. Client processing 272 4.1. TACK pins 274 A client SHALL have a local store of pins, and MAY have multiple 275 stores. Each pin store consists of a map associating fully qualified 276 DNS hostnames with either one or two sets of the following values: 278 Initial time: A timestamp noting when this pin was created. 280 End time: A timestamp determining the pin's "active period". If set 281 to zero or a time in the past, the pin is "inactive". If set to a 282 future time, the pin is "active" until that time. 284 TSK public key (or hash): A public key or a cryptographically- 285 secure, second preimage-resistant hash of a public key. 287 Min_generation: A single byte used to detect revoked tacks. All 288 pins within a pin store sharing the same TSK SHALL have the same 289 min_generation. 291 A hostname along with the above values comprises a "TACK pin". Thus, 292 each store can hold up to two pins for a hostname (however, those two 293 pins MUST reference different public keys). A pin "matches" a tack 294 if they reference the same public key. A pin is "relevant" if its 295 hostname equals the TLS server's hostname. 297 4.2. High-level client processing 299 A TACK client SHALL send the "tack" extension defined previously, and 300 SHALL send the "server_name" extension from [RFC6066]. If not 301 resuming a session, the server MAY respond with a TackExtension. 302 Regardless of whether a TackExtension is returned, the client SHALL 303 perform the following steps prior to using the connection: 305 1. Check whether the TLS handshake is "valid". 307 2. For each pin store, do: 309 A. Check tack generations and update min_generations. 311 B. Determine the store's status. 313 C. Perform pin activation (optional). 315 These steps SHALL be performed in order. If there is any error, the 316 client SHALL send a fatal error alert and close the connection, 317 skipping the remaining steps (see Section 4.3 for details). 319 Based on step 2B, each store will report one of three statuses for 320 the connection: "confirmed", "contradicted", or "unpinned". A 321 contradicted connection might indicate a network attack. How the 322 client responds to confirmed or contradicted connections is left to 323 other specifications and client policy (see Section 5.3 for an 324 example). If a client closes a connection due to a contradicting 325 pin, the client SHALL send an "access_denied" alert. 327 4.3. Client processing details 329 4.3.1. Check whether the TLS handshake is valid 331 A TLS handshake is "valid" if the following are true. Unless 332 otherwise specified, if any of the following are false a 333 "bad_certificate" fatal error alert SHALL be sent. 335 1. The handshake protocol negotiates a cryptographically secure 336 ciphersuite and finishes succesfully. 338 2. If a TackExtension is present then all length fields are correct 339 and the tacks are "valid" (see below). 341 3. If there are two tacks, they have different "public_key" fields. 343 A tack is "valid" if: 345 1. "generation" is >= "min_generation". 347 2. "expiration" specifies a time in the future, otherwise the client 348 SHALL send a fatal "certificate_expired" error alert. 350 3. "target_hash" is a correct hash of the SubjectPublicKeyInfo. 352 4. "signature" is a correct ECDSA signature. 354 4.3.2. Check tack generations and update min_generations 356 If a tack has matching pins in the pin store and a generation less 357 than the stored min_generation, then that tack is revoked and the 358 client SHALL send a fatal "certificate_revoked" error alert. If a 359 tack has matching pins and a min_generation greater than the stored 360 min_generation, the stored value SHALL be set to the tack's value. 362 4.3.3. Determine the store's status 364 If there is a relevant active pin without a matching tack, then the 365 connection is "contradicted". If the connection is not contradicted 366 and there is a relevant active pin with a matching tack, then the 367 connection is "confirmed". Otherwise, the connection is "unpinned". 369 4.3.4. Pin activation (optional) 371 The TLS connection MAY be used to create, delete, and activate pins. 372 This "pin activation algorithm" is optional; a client MAY rely on an 373 external source of pins. If the connection was "contradicted" by the 374 previous processing step, then pin activation is skipped. 376 The first step is to evaluate each of the (0, 1, or 2) relevant pins: 378 1. If a pin has no matching tack, its handling will depend on 379 whether the pin is active. If active, the connection will have 380 been contradicted, skipping pin activation. If inactive, the pin 381 SHALL be deleted. 383 2. If a pin has a matching tack, its handling will depend on whether 384 the tack is active. If inactive, the pin is left unchanged. If 385 active, the pin SHALL have its "end time" set based on the 386 current, initial, and end times: 388 end = current + MIN(30 days, current - initial) 390 In sum: (1) deletes unmatched inactive pins, and (2) activates 391 matched pins with active tacks. 393 The remaining step is to add new inactive pins for any unmatched 394 active tacks. Each new pin uses the server's hostname, the tack's 395 public key and min_generation (unless the store has a higher 396 min_generation for the public key), an "initial time" set to the 397 current time, and an "end time" of zero. (Note that there are always 398 sufficient empty "slots" in the pin store for adding new pins without 399 exceeding two pins per hostname.) 401 The following tables summarize this behavior from the perspective of 402 a pin. You can follow the lifecycle of a single pin from "New 403 inactive pin" to "Delete pin". 405 Relevant pin is active: 407 +--------------------+----------------+---------------------------+ 408 | Pin matches a tack | Tack is active | Result | 409 +--------------------+----------------+---------------------------+ 410 | Yes | Yes | Extend activation period | 411 | | | | 412 | Yes | No | - | 413 | | | | 414 | No | - | (Connection contradicted) | 415 +--------------------+----------------+---------------------------+ 417 Relevant pin is inactive: 419 +--------------------+----------------+--------------+ 420 | Pin matches a tack | Tack is active | Result | 421 +--------------------+----------------+--------------+ 422 | Yes | Yes | Activate pin | 423 | | | | 424 | Yes | No | - | 425 | | | | 426 | No | - | Delete pin | 427 +--------------------+----------------+--------------+ 429 Tack doesn't match any relevant pin: 431 +--------------------------+------------------+ 432 | Unmatched tack is active | Result | 433 +--------------------------+------------------+ 434 | Yes | New inactive pin | 435 | | | 436 | No | - | 437 +--------------------------+------------------+ 439 5. Application protocols and TACK 441 5.1. Pin scope 443 TACK pins are specific to a particular application protocol. In 444 other words, a pin for HTTPS at "example.com" implies nothing about 445 POP3 or SMTP at "example.com". 447 5.2. TLS negotiation 449 Some application protocols negotiate TLS as an optional feature (e.g. 450 SMTP using STARTTLS [RFC3207]). If such a server does not negotiate 451 TLS and there are relevant active pins, then the connection is 452 contradicted by the pin. If a client is performing pin activation 453 for a pin store and the server does not negotiate TLS, then any 454 relevant, inactive pins SHALL be deleted. Note that these steps are 455 taken despite the absence of a TLS connection. 457 5.3. Certificate verification 459 A TACK client MAY choose to perform some form of certificate 460 verification in addition to TACK processing. When combining 461 certificate verification and TACK processing, the TACK processing 462 described in Section 4 SHALL be followed, with the exception that 463 TACK processing MAY be terminated early (or skipped) if some fatal 464 certificate error is discovered. 466 If TACK processing and certificate verification both complete without 467 a fatal error, then client behavior is left to other specifications 468 and client policy. An example client policy would be to allow the 469 connection to proceed only if it passes certificate verification and 470 is not contradicted by a pin. 472 6. Fingerprints 474 A "key fingerprint" may be used to represent a TSK public key to 475 users in a form that is easy to compare and transcribe. A key 476 fingerprint consists of the first 25 characters from the base32 477 encoding of SHA256(public_key), split into 5 groups of 5 characters 478 separated by periods. Base32 encoding is as specified in [RFC4648], 479 except lowercase is used. Examples: 481 g5p5x.ov4vi.dgsjv.wxctt.c5iul 483 quxiz.kpldu.uuedc.j5znm.7mqst 485 e25zs.cth7k.tscmp.5hxdp.wf47j 487 7. Advice 489 7.1. For server operators 491 Key reuse: All servers that are pinned to a single TSK are able to 492 impersonate each other's hostnames, since clients will perceive 493 their tacks as equivalent. Thus, TSKs SHOULD NOT be reused with 494 different hostnames unless these hostnames are closely related. 495 Examples where it would be safe to reuse a TSK are hostnames 496 aliased to the same host, hosts sharing the same TLS key, or 497 hostnames for a group of near-identical servers. 499 Aliases: A TLS server might be referenced by multiple hostnames. 500 Clients might pin any of these hostnames. Server operators should 501 be careful when using DNS aliases that hostnames are not pinned 502 inadvertently. 504 Generations: To revoke older generations of tacks, the server 505 operator SHOULD first provide all servers with a new generation of 506 tacks, and only then provide servers with new tacks containing the 507 new min_generation. Otherwise, a client might receive a 508 min_generation update from one server but then try to contact an 509 older-generation server which has not yet been updated. 511 Tack expiration: When TACK is used in conjunction with certificates 512 it is recommended to set the tack expiration equal to the end- 513 entity certificate's expiration (or a later date), so that the 514 tack and certificate can both be replaced at the same time. 515 Alternatively, short-lived tacks MAY be used so that a compromised 516 TLS private key has limited value to an attacker. 518 Nonrevokable tacks A tack with generation 255 cannot be revoked. 519 Such tacks MAY be used to minimize the risk that a compromised TSK 520 private key could be used to affect site availability. 522 Tack/pin activation: Tacks should only be activated once all TLS 523 servers sharing the same hostname have a tack. Otherwise, a 524 client may activate a pin by contacting one server, then contact a 525 different server at the same hostname that does not yet have a 526 tack. 528 Tack/pin deactivation: If all servers at a hostname deactivate their 529 tacks (by clearing the activation flags), all existing pins for 530 the hostname will eventually become inactive. The tacks can be 531 removed after a time interval equal to the maximum active period 532 of any affected pins (30 days at most). 534 Tack/pin overlap: When publishing overlapping tacks, the old and new 535 tacks SHOULD be active simultaneously for at least 60 days. This 536 ensures that any pin activation client who is contacting the 537 server at intervals of 30 days or less will not have its 538 activation periods interrupted. Example process: activate new 539 tacks; wait 60 days; deactivate old tacks; wait 30 days; remove 540 old tacks. 542 7.2. For client implementers 544 Sharing pin information: It is possible for a client to maintain a 545 pin store based entirely on its own TLS connections. However, 546 such a client runs the risk of creating incorrect pins, failing to 547 keep its pins active, or failing to receive min_generation 548 updates. Clients are advised to make use of 3rd-party trust 549 infrastructure so that pin data can be aggregated and shared. 550 This will require additional protocols outside the scope of this 551 document. 553 Clock synchronization: A client SHOULD take measures to prevent 554 tacks from being erroneously rejected as expired due to an 555 inaccurate client clock. Such methods MAY include using time 556 synchronization protocols such as NTP [RFC5905], or accepting 557 seemingly-expired tacks as valid if they expired less than T 558 minutes ago, where T is a "tolerance bound" set to the client's 559 maximum expected clock error. 561 8. Security considerations 563 8.1. For server operators 565 All servers pinned to the same TSK can impersonate each other (see 566 Section 7.1). Think carefully about this risk if using the same TSK 567 for multiple hostnames. 569 Make backup copies of the TSK private key and keep all copies in 570 secure locations where they can't be compromised. 572 A TSK private key MUST NOT be used to perform any non-TACK 573 cryptographic operations. For example, using a TSK for email 574 encryption, code-signing, or any other purpose MUST NOT be done. 576 HTTP cookies [RFC6265] set by a pinned host can be stolen by a 577 network attacker who can forge web and DNS responses so as to cause a 578 client to send the cookies to a phony subdomain of the pinned host. 579 To prevent this, TACK HTTPS servers SHOULD set the "secure" attribute 580 and omit the "domain" attribute on all security-sensitive cookies, 581 such as session cookies. These settings tell the browser that the 582 cookie should only be presented back to the originating host (not its 583 subdomains), and should only be sent over HTTPS (not HTTP) [RFC6265]. 585 8.2. For client implementers 587 A TACK pin store may contain private details of the client's 588 connection history. An attacker may be able to access this 589 information by hacking or stealing the client. Some information 590 about the client's connection history could also be gleaned by 591 observing whether the client accepts or rejects connections to phony 592 TLS servers without correct tacks. To mitigate these risks, a TACK 593 client SHOULD allow the user to edit or clear the pin store. 595 Aside from possibly rejecting TLS connections, clients SHOULD NOT 596 take any actions which would reveal to a network observer the state 597 of the client's pin store, as this would allow an attacker to know in 598 advance whether a "man-in-the-middle" attack on a particular TLS 599 connection will succeed or be detected. 601 An attacker may attempt to flood a client with spurious tacks for 602 different hostnames, causing the client to delete old pins to make 603 space for new ones. To defend against this, clients SHOULD NOT 604 delete active pins to make space for new pins. Clients instead 605 SHOULD delete inactive pins. If there are no inactive pins to 606 delete, then the pin store is full and there is no space for new 607 pins. To select an inactive pin for deletion, the client SHOULD 608 delete the pin with the oldest "end time". 610 8.3. Note on algorithm agility 612 If the need arises for tacks using different cryptographic algorithms 613 (e.g., if SHA256 or ECDSA are shown to be weak), a "v2" version of 614 tacks could be defined, requiring assignment of a new TLS Extension 615 number. Tacks as defined in this document would then be known as 616 "v1" tacks. 618 9. IANA considerations 620 9.1. New entry for the TLS ExtensionType Registry 622 IANA is requested to add an entry to the existing TLS ExtensionType 623 registry, defined in [RFC5246], for "tack"(TBD) as defined in this 624 document. 626 10. Acknowledgements 628 Valuable feedback has been provided by Adam Langley, Chris Palmer, 629 Nate Lawson, and Joseph Bonneau. 631 11. Normative references 633 [FIPS180-2] 634 National Institute of Standards and Technology, "Secure 635 Hash Standard", FIPS PUB 180-2, August 2002, . 638 [FIPS186-3] 639 National Institute of Standards and Technology, "Digital 640 Signature Standard", FIPS PUB 186-3, June 2009, . 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 647 Transport Layer Security", RFC 3207, February 2002. 649 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 650 Encodings", RFC 4648, October 2006. 652 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 653 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 655 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 656 Housley, R., and W. Polk, "Internet X.509 Public Key 657 Infrastructure Certificate and Certificate Revocation List 658 (CRL) Profile", RFC 5280, May 2008. 660 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, 661 "Elliptic Curve Cryptography Subject Public Key 662 Information", RFC 5480, March 2009. 664 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 665 Time Protocol Version 4: Protocol and Algorithms 666 Specification", RFC 5905, June 2010. 668 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 669 Extension Definitions", RFC 6066, January 2011. 671 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 672 Curve Cryptography Algorithms", RFC 6090, February 2011. 674 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 675 April 2011. 677 Authors' Addresses 679 Moxie Marlinspike 681 Trevor Perrin (editor) 683 Email: tack@trevp.net