TACK

TACK (Tethered Assertions for Certificate Keys)

Rationale

The Convergence system is very effective at introducing clients to servers. The Convergence client then caches the server's certificate for future use.

If the cached certificate changes in the future, the client will contact Convergence notaries. This mitigates local attacks (the common case) but not global attacks which replace the server from all network viewpoints.

To eliminate the overhead of this notary contact and to provide security against global attacks, TACK provides a mechanism for sites to cryptographically sign their certificate changes. This enables clients to verify certificate changes at TACK-enabled sites without relying on notaries, giving even more efficient, reliable, and secure connections.

Non-Convergence clients can use TACK as well. Without the full Convergence system, a client's initial connection to a site will have to rely on existing browser security mechanisms. However, subsequent connections will be strongly protected.

Overview

TACK allows an SSL site to advertise certificate requirements to clients which they must validate on subsequent connections. In particular, TACK allows a site to specify a TACK public key which the site uses to sign some public key or certificate in the site's certificate chain.

This TACK key and signature are distinct from the SSL keys and signatures comprising the site's certificate chain, and they are ignored by non-TACK-aware clients.

Delivery Mechanism

Pinning of SSL certificates is something that should be asserted and validated at the SSL level. In order to communicate a TACK assertion, the server includes a "superfluous" certificate in the SSL certificate chain that it presents to the user.

For instance, a normal SSL certificate chain for an end-entity such as thoughtcrime.org might look like this:

VeriSign Level 1
   |
   ---> VeriSign Intermediate CA
           |
           ---> www.thoughtcrime.org

If thoughtcrime.org were to assert TACK rules, however, the certificate chain would look like this:

TACK Certificate (self-signed)
VeriSign Level 1
   |
   ---> VeriSign Intermediate CA
           |
           ---> www.thoughtcrime.org

A certificate containing TACK information is merely included in the SSL/TLS Certificate message (it is not strictly part of the chain, since it doesn't sign anything other than itself). Clients that do not understand TACK will simply ignore it, while clients that do understand TACK will parse it to interpret the TACK extensions.

The TACK certificate extensions have been designed so that in the future they could be transmitted over TLS Extensions. For the time being TACK certificates offer the simplest route to deployment since they do not require server operators to patch their TLS libraries.

We've set up a test server with a TACK and - in light testing - did not see any browser compatibility problems. See https://test1.trevp.net.

TACK Pins

To use TACK, thoughtcrime.org would provide a TACK certificate which contains a v3 extension that contains a TACK public signing key. This is a key that the site controls, and which can be used to sign any SubjectPublicKeyInfo or certificate in the site's certificate chain, including the site's end-entity certificate.

Upon processing the TACK structure, the client stores a local "pin" to the TACK public key and some associated data (e.g. expiration time). A client relying on this TACK pin will ensure that all future certificate chains for thoughtcrime.org are provided with a TACK certificate containing a valid TACK signature matching the TACK pin.

TACK Pin Breaking

A site might wish to stop maintaining its TACK signatures, or may lose trust in and wish to revoke its TACK public key. To do this, TACK certificates may contain a list of "pin break signatures". These are signed statements by a TACK public key disavowing a TACK pin.

In the future, if a browser contacts the site and detects a mismatch between a stored pin and the certificate chain, the browser will check the TACK certificate extension specifying a list of break signatures. If one of the break signatures verifies against the stored pin, the browser will delete the pin and behave as if it was contacting the site for the first time (e.g. by checking with Convergence notaries).

If there is a pin mismatch and no break signature for the pin, the browser will reject the connection.

Structure of a TACK Certificate

To recap, a TACK certificate has the standard X.509 structure with two optional extensions:

X509 Certificate
   Version
   Serial Number
   Algorithm ID
   Issuer ('TACK')
   Validity
      Not Before
      Not After
   Subject ('TACK')
   Subject Public Key Info
      Public Key Algorithm
      Subject Public Key
   Extensions
      TACK                  (Optional)
      TACK Break Signatures (Optional)

The TACK structure contains the TACK pin and signature.

If older pins have been broken then TACK Break Signatures is present. TACK Break Signatures may appear by itself if the site wishes to break old pins but not create a new one.

The following extension definitions use the SSL presentation language defined in RFC 2246.

Structure of TACK Extension

enum {v1(1)} TACK_Pin_Type;
enum {v1_cert(1), v1_key(2)} TACK_Sig_Type;

struct {
   TACK_Pin_Type pin_type;
   opaque pin_key[64];
   opaque pin_label[8];
} TACK_Pin;

struct TACK_Sig {
   TACK_Sig_Type sig_type;
   uint32 sig_expiration;
   uint8  sig_generation;
   opaque sig_target_sha256[32];
   opaque signature[64];
} TACK_Sig;

struct {
	TACK_Pin pin;
	TACK_Sig sig;
	uint32 pin_duration;
} TACK;

• "pin_key" is an elliptic curve public key on the NIST P-256 curve.
• "pin_label" allows a single public key to be used with different TACK pins.
• "sig_expiration" is a uint32 encoding UNIX time / 60. The signature will be rejected by a client if the expiration time has elapsed. Sites could mitigate the risk of SSL key compromise by using shorter-lived signatures.
• "sig_generation" assigns each signature a generation. A client should store the largest value of sig_generation it has seen for a given pin. A signature will be rejected if its sig_generation is less than the stored value. This allows a site to explicitly revoke earlier generations of signatures that have not yet expired. Upon receiving a new value for sig_generation, the client should allow a 24 hour grace period before rejecting previous generations, to allow time for all servers in a large site to be updated.
• "sig_target_sha256" is a SHA256 hash of either a SubjectPublicKeyInfo field from an X.509 certificate (if sig_type=v1_key), or an entire X.509 certificate (if sig_type=v1_cert) in the current SSL Certificate chain.
• "signature" is an ECDSA-P256-SHA256 signature over the entire TACK structure prior to the "signature" field.
• "pin_duration" is a uint32 encoding a number of minutes. The pin will be discarded by a client after this many minutes has elapsed. Upon successfully validating a TACK and performing the TLS handshake, the client will updates its stored pin expiration time based upon pin_duration.

Structure of TACK Break Signatures Extension

struct {
    opaque break_label[8];
    opaque break_signature[64];
} TACK_Break_Sig;

struct {
   TACK_Break_Sig break_sigs<0...1440>
} TACK_Break_Sigs;

• "break_signature" is an ECDSA-P256-SHA256 signature over the 8 bytes of a "pin_label" from the public key matching that label.

Details of TACK fields

• The public key field "out_of_chain_key" is a pair of nonnegative integers (x,y) representing a point on the elliptic curve P-256 defined in FIPS 186-3. Each integer is less than 2^256. Each integer is encoded as a 32-byte octet string using the Integer-to-Octet-String algorithm from SEC1, and these strings are concatenated with the x value first to produce a 64-byte octet string. (NOTE: This is equivalent to an uncompressed subjectPublicKey from SEC1, except that the initial 0x04 byte from subjectPublicKey is omitted).

• The signature field "signature" is a pair of nonnegative integers (r,s) representing an ECDSA signature as defined in FIPS 186-3. Each integer is less than 2^256. Each integer is encoded as a 32-byte octet string using the Integer-to-Octet-String algorithm from SEC1, and these strings are concatenated with the r value first to produce a 64-byte octet string. (NOTE: This differs from ECDSA-Sig-Value in SEC1 which conveys the integers inside an ASN.1 sequence. Since ECDSA-Sig-Value is variable-length, and unnecessarily complex for this application, it was avoided).

• The "pin_expiration", "sig_expiration", and "sig_generation" fields specify a check that is applied to the current UTC time to determine whether the TACK Pin (or TACK Signature) should be accepted or rejected. If the current UTC time, when converted to an integer via the algorithm in POSIX.1, is less than the value pin_expiration*60 (or sig_expiration*60, or sig_generation*60), the check passes and the structure is accepted. Otherwise, the structure is rejected.

Editors

• Moxie Marlinspike and Trevor Perrin.

Acknowledgements

Valuable feedback has been provided by: Adam Langley, Chris Palmer, Nate Lawson, and Joseph Bonneau.