TACK

== TACK (Tethered Assertions for Certificate Keys)

== Rationale

Convergence notaries employing network perspective (the default notary strategy) are 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 have to contact the notaries again. This is effective in mitigating //local// attacks which only control some paths to the server (the vastly common case), but it would also be nice to protect against //global// attacks by those who control the DNS or routing for a site.

Network perspective notaries can alert clients when certificates change, but TACK provides an explicit mechanism for sites to assert what changes are allowable. When combined with a secure introduction mechanism like Convergence notaries, it provides a system which protects against both local and global attackers.

== 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 site-controlled public key which must 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 as well as TACK certificates. 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 test servers with superfluous certificates and - in light testing - did not see any browser compatibility problems. See https://test1.trevp.net and https://test2.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 specified 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_key(1), v1_cert(2)} TACK_Sig_Type;

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

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

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

• "pin_expiration" is a uint32 encoding UNIX time / 60. The pin will be discarded by a client if the expiration time has elapsed. Upon successfully validating a TACK and performing the TLS handshake, the client should record the most-recently-seen value of "pin_expiration".
• "pin_label" allows a single public key to be used with different TACK pins. It is also used to match a TACK pin against a break signature.
• "pin_key" is an elliptic curve public key on the NIST P-256 curve.
• "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" is a uint32 encoding UNIX time / 60. A client should store the largest value of sig_generation it has seen for a given pin. The signature will be rejected if its sig_generation is earlier than the stored value, and the current time is later than sig_generation. This allows a site to revoke earlier generations of signatures, effective as of "sig_generation" time.
• "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 49 bytes value consisting of TACK_Sig from the "sig_type" up to the "signature", followed by "pin_label".

== 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_expiration60 (or sig_expiration60), the check passes and the structure is accepted. Otherwise, the structure is rejected.

== Editors

• Moxie Marlinspike and Trevor Perrin.