Merge remote-tracking branch 'origin/master' into 269-change-kdf

7 files changed, 317 insertions, 63 deletions

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index d0376cd..f049d76 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -144,7 +144,7 @@ Proposals by number:
 221  Stop using CREATE_FAST [CLOSED]
 222  Stop sending client timestamps [CLOSED]
 223  Ace: Improved circuit-creation key exchange [RESERVE]
-224  Next-Generation Hidden Services in Tor [DRAFT]
+224  Next-Generation Hidden Services in Tor [OPEN]
 225  Strawman proposal: commit-and-reveal shared rng [SUPERSEDED]
 226  "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS" [OPEN]
 227  Include package fingerprints in consensus documents [CLOSED]
@@ -184,7 +184,7 @@ Proposals by number:
 261  AEZ for relay cryptography [OPEN]
 262  Re-keying live circuits with new cryptographic material [OPEN]
 263  Request to change key exchange protocol for handshake v1.2 [OBSOLETE]
-264  Putting version numbers on the Tor subprotocols [OPEN]
+264  Putting version numbers on the Tor subprotocols [FINISHED]
 265  Load Balancing with Overhead Parameters [ACCEPTED]
 266  Removing current obsolete clients from the Tor network [DRAFT]
 267  Tor Consensus Transparency [DRAFT]
@@ -192,7 +192,8 @@ Proposals by number:
 269  Transitionally secure hybrid handshakes [DRAFT]
 270  RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope [DRAFT]
 271  Another algorithm for guard selection [OPEN]
-272  Listed routers should be Valid, Running, and treated as such [OPEN]
+272  Listed routers should be Valid, Running, and treated as such [FINISHED]
+273  Exit relay pinning for web services [DRAFT]
 
 
 Proposals by status:
@@ -200,7 +201,6 @@ Proposals by status:
  DRAFT:
    195  TLS certificate normalization for Tor 0.2.4.x [for 0.2.4.x]
    203  Avoiding censorship by impersonating an HTTPS server
-   224  Next-Generation Hidden Services in Tor
    230  How to change RSA1024 relay identity keys [for 0.2.?]
    231  Migrating authority RSA1024 identity keys [for 0.2.?]
    239  Consensus Hash Chaining
@@ -221,6 +221,7 @@ Proposals by status:
    268  New Guard Selection Behaviour
    269  Transitionally secure hybrid handshakes
    270  RebelAlliance: A Post-Quantum Secure Hybrid Handshake Based on NewHope
+   273  Exit relay pinning for web services [for n/a]
  NEEDS-REVISION:
    190  Bridge Client Authorization Based on a Shared Secret
  NEEDS-RESEARCH:
@@ -240,6 +241,7 @@ Proposals by status:
    210  Faster Headless Consensus Bootstrapping [for 0.2.8.x+]
    212  Increase Acceptable Consensus Age [for 0.2.4.x+]
    219  Support for full DNS and DNSSEC resolution in Tor [for 0.2.5.x]
+   224  Next-Generation Hidden Services in Tor
    226  "Scalability and Stability Improvements to BridgeDB: Switching to a Distributed Database System and RDBMS"
    229  Further SOCKS5 extensions
    233  Making Tor2Web mode faster
@@ -250,9 +252,7 @@ Proposals by status:
    256  Key revocation for relays and authorities
    261  AEZ for relay cryptography
    262  Re-keying live circuits with new cryptographic material
-   264  Putting version numbers on the Tor subprotocols
    271  Another algorithm for guard selection
-   272  Listed routers should be Valid, Running, and treated as such
  ACCEPTED:
    140  Provide diffs between consensuses
    172  GETINFO controller option for circuit information
@@ -281,6 +281,8 @@ Proposals by status:
    217  Tor Extended ORPort Authentication [for 0.2.5.x]
    232  Pluggable Transport through SOCKS proxy [in 0.2.6]
    235  Stop assigning (and eventually supporting) the Named flag [in 0.2.6, 0.2.7]
+   264  Putting version numbers on the Tor subprotocols [in 0.2.9.4-alpha]
+   272  Listed routers should be Valid, Running, and treated as such [in 0.2.9.3-alpha, 0.2.9.4-alpha]
  CLOSED:
    101  Voting on the Tor Directory System [in 0.2.0.x]
    102  Dropping "opt" from the directory format [in 0.2.0.x]
diff --git a/proposals/220-ecc-id-keys.txt b/proposals/220-ecc-id-keys.txt
index 7a21f20..dd063e8 100644
--- a/proposals/220-ecc-id-keys.txt
+++ b/proposals/220-ecc-id-keys.txt
@@ -670,3 +670,11 @@ A.5. Reserved numbers
         6: TLS authentication key certified by Ed25519 signing key
         7: RSA cross-certificate for Ed25519 identity key
 
+
+A.6. Related changes
+
+   As we merge this, proposal, we should also extend link key size to
+   2048 bits, and use SHA256 as the x509 cert algorithm for our link
+   keys. This will improve link security, and deliver better
+   fingerprinting resistence.  See proposal 179 for an older discussion
+   of this issue.
diff --git a/proposals/224-rend-spec-ng.txt b/proposals/224-rend-spec-ng.txt
index 3b41403..558cf1f 100644
--- a/proposals/224-rend-spec-ng.txt
+++ b/proposals/224-rend-spec-ng.txt
@@ -2,7 +2,7 @@ Filename: 224-rend-spec-ng.txt
 Title: Next-Generation Hidden Services in Tor
 Author: Nick Mathewson
 Created: 2013-11-29
-Status: Draft
+Status: Open
 
 Table of contents:
 
@@ -35,7 +35,7 @@ Table of contents:
         2.3. Publishing shared random values [PUB-SHAREDRANDOM]
             2.3.1. Client behavior in the absense of shared random values
             2.3.2. Hidden services and changing shared random values
-            2.4. Hidden service descriptors: outer wrapper [DESC-OUTER]
+        2.4. Hidden service descriptors: outer wrapper [DESC-OUTER]
         2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA]
     3. The introduction protocol
         3.1. Registering an introduction point [REG_INTRO_POINT]
@@ -691,8 +691,9 @@ Table of contents:
 
 2.2.2. When to publish a hidden service descriptor [WHEN-HSDESC]
 
-   Hidden services periodically publish their descriptor to the responsible HSDirs.
-   The set of responsible HSDirs is determined as specified in [WHERE-HSDESC].
+   Hidden services periodically publish their descriptor to the responsible
+   HSDirs. The set of responsible HSDirs is determined as specified in
+   [WHERE-HSDESC].
 
    Specifically, everytime a hidden service publishes its descriptor, it also
    sets up a timer for a random time between 60 minutes and 120 minutes in the
@@ -709,7 +710,8 @@ Table of contents:
    overwhelmed by every host uploading at the same time.
 
    To avoid this thundering herd problem, hidden services upload descriptors
-   for the upcoming time period at a random time _before_ the time period starts.
+   for the upcoming time period at a random time _before_ the time period
+   starts.
 
    For the above "descriptor overlap" system to work, fresh shared random
    values must be available multiple hours *before* the time period changes, so
@@ -763,8 +765,8 @@ Table of contents:
                                  INT_8(period_num) )
 
    where shared_random_value is the shared value generated by the authorities
-   in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity key
-   of the node.
+   in section [PUB-SHAREDRANDOM], and node_identity is the ed25519 identity
+   key of the node.
 
    Finally, for replicanum in 1...hsdir_n_replicas, the hidden service
    host uploads descriptors to the first hsdir_spread_store nodes whose
@@ -835,12 +837,12 @@ Table of contents:
 
 2.2.6. URLs for anonymous uploading and downloading
 
-   Hidden service descriptors conforming to this specification are
-   uploaded with an HTTP POST request to the URL
-   /tor/rendezvous3/publish relative to the hidden service directory's
-   root, and downloaded with an HTTP GET request for the URL
-   /tor/rendezvous3/<z> where z is a base-64 encoding of the hidden
-   service's blinded public key.
+   Hidden service descriptors conforming to this specification are uploaded
+   with an HTTP POST request to the URL /tor/hs/<version>/publish relative to
+   the hidden service directory's root, and downloaded with an HTTP GET
+   request for the URL /tor/hs/<version>/<z> where <z> is a base64 encoding of
+   the hidden service's blinded public key and <version> is the protocol
+   version which is "3" in this case.
 
    These requests must be made anonymously, on circuits not used for
    anything else.
@@ -893,7 +895,7 @@ Table of contents:
 
        [At start, exactly once.]
 
-       The version-number contains a positive integer indicating the version
+       The version-number is a 32 bit unsigned integer indicating the version
        of the descriptor. Current version is "3".
 
      "descriptor-lifetime" SP LifetimeMinutes NL
@@ -901,7 +903,8 @@ Table of contents:
        [Exactly once]
 
        The lifetime of a descriptor in minutes. An HSDir SHOULD expire the
-       hidden service descriptor at least LifetimeMinutes after it was uploaded.
+       hidden service descriptor at least LifetimeMinutes after it was
+       uploaded.
 
        The LifetimeMinutes field can take values between 30 and 3000 (50 hours).
 
@@ -941,9 +944,10 @@ Table of contents:
        [exactly once, at end.]
 
        A signature of all previous fields, using the signing key in the
-       descriptor-signing-key-cert line. We use a separate key for signing, so that
-       the hidden service host does not need to have its private blinded
-       key online.
+       descriptor-signing-key-cert line, prefixed by the string "Tor onion
+       service descriptor sig v3". We use a separate key for signing, so that
+       the hidden service host does not need to have its private blinded key
+       online.
 
 2.5. Hidden service descriptors: encryption format [ENCRYPTED-DATA]
 
@@ -954,7 +958,8 @@ Table of contents:
               descriptor even if the content of the descriptor hasn't changed.
               (So that we don't leak whether the intro point list etc. changed)
 
-       secret_input = blinded_public_key | subcredential | INT_8(revision_counter)
+       secret_input = blinded_public_key | subcredential |
+                      INT_8(revision_counter)
        keys = KDF(secret_input, salt, "hsdir-encrypted-data",
                   S_KEY_LEN + S_IV_LEN + MAC_KEY_LEN)
 
@@ -1036,17 +1041,17 @@ Table of contents:
           Cross-certification of the descriptor signing key by the enc-key.
           The format of this certificate depends on the type of enc-key.
 
-          For "ntor" keys, certificate is a proposal 220 certificate in
-          "-----BEGIN ED25519 CERT-----" armor, cross-certifying the
+          For "ntor" keys, certificate is a proposal 220 certificate wrapped
+          in "-----BEGIN ED25519 CERT-----" armor, cross-certifying the
           descriptor signing key with the ed25519 equivalent of the curve25519
           public key from "enc-key" derived using the process in proposal 228
           appendix A. The certificate type must be [10], and the signing-key
           extension is mandatory.
 
-          For "legacy" keys, certificate is an RSA signature wrapped in
-          "-----BEGIN SIGNATURE-----" of the digest:
-              H("legacy introduction point encryption key" | ED25519_KEY)
-          ED25519_KEY is the 32 byte descriptor signing public key.
+          For "legacy" keys, certificate is a proposal 220 RSA->Ed
+          cross-certificate wrapped in "-----BEGIN CROSSCERT-----" armor,
+          cross-certifying the descriptor signing key with the legacy RSA
+          encryption key.
 
    To remain compatible with future revisions to the descriptor format,
    clients should ignore unrecognized lines in the descriptor.
@@ -1136,7 +1141,8 @@ Table of contents:
    Otherwise, the node must associate the key with the circuit, for use
    later in INTRODUCE1 cells.
 
-3.1.2. Registering an introduction point on a legacy Tor node [LEGACY_EST_INTRO]
+3.1.2. Registering an introduction point on a legacy Tor node
+       [LEGACY_EST_INTRO]
 
    Tor nodes should also support an older version of the ESTABLISH_INTRO
    cell, first documented in rend-spec.txt. New hidden service hosts
@@ -1354,7 +1360,8 @@ Table of contents:
    Note that the old TAP-derived protocol of the previous hidden service
    design achieved the first two requirements, but not the third.
 
-3.3.2. Example encryption handshake: ntor with extra data [NTOR-WITH-EXTRA-DATA]
+3.3.2. Example encryption handshake: ntor with extra data
+       [NTOR-WITH-EXTRA-DATA]
 
    [TODO: relocate this]
 
@@ -1820,8 +1827,8 @@ Appendix E. Reserved numbers
            public key. (Section 2.4)
       [09] intro point authentication key, cross-certifying the descriptor
            signing key. (Section 2.5)
-      [10] ed25519 key derived from the curve25519 intro point encryption key,
+      [0B] ed25519 key derived from the curve25519 intro point encryption key,
            cross-certifying the descriptor signing key. (Section 2.5)
 
-  [XXXX list more]
-
+      Note: The value "0A" is skipped because it's reserved for the onion key
+            cross-certifying ntor identity key from proposal 228.
diff --git a/proposals/244-use-rfc5705-for-tls-binding.txt b/proposals/244-use-rfc5705-for-tls-binding.txt
index d1a51fe..c4369b3 100644
--- a/proposals/244-use-rfc5705-for-tls-binding.txt
+++ b/proposals/244-use-rfc5705-for-tls-binding.txt
@@ -21,7 +21,7 @@ Status: Accepted
   and TYPE field to be determined, that works the same as our current
   "RSA-SHA256-TLSSecret" authentication, except for these fields:
 
-    TYPE is a different constant string.
+    TYPE is a different constant string, "AUTH0002".
 
     TLSSECRETS is replaced by the output of the Exporter function in
     RFC5705, using as its inputs:
@@ -29,10 +29,10 @@ Status: Accepted
         * The context value equal to the client's identity key digest.
         * The length 32.
 
-  I propose that proposal 224's section on authenticating with ed25519
+  I propose that proposal 220's section on authenticating with ed25519
   keys be amended accordingly:
 
-    TYPE is a different constant string, different from the one above.
+    TYPE is a different constant string, "AUTH0003".
 
     TLSSECRETS is replaced by the output of the Exporter function in
     RFC5705, using as its inputs:
diff --git a/proposals/264-subprotocol-versions.txt b/proposals/264-subprotocol-versions.txt
index e4357e5..5375d82 100644
--- a/proposals/264-subprotocol-versions.txt
+++ b/proposals/264-subprotocol-versions.txt
@@ -2,7 +2,8 @@ Filename: 264-subprotocol-versions.txt
 Title: Putting version numbers on the Tor subprotocols
 Author: Nick Mathewson
 Created: 6 Jan 2016
-Status: Open
+Status: Finished
+Implemented-In: 0.2.9.4-alpha
 
 
 1. Introduction
@@ -72,7 +73,8 @@ Status: Open
    "x-" or "X-".  Keywords are case-sensitive.
 
    During voting, authorities copy these lines immediately below the "v"
-   lines. When a descriptor does not contain a "proto" entry, the
+   lines, using "pr" as the keyword instead of "proto".
+   When a descriptor does not contain a "proto" entry, the
    authorities should reconstruct it using the approach described below
    in section A.1.  They are included in the consensus using the same
    rules as currently used for "v" lines, if a sufficiently late
@@ -104,7 +106,7 @@ Status: Open
    inferrable from the v line.  Removing all the v lines from the
    current consensus would save only 1.7% after gzip compression.]
 
-3. Using "proto" and "v" lines
+3. Using "proto"/"pr" and "v" lines
 
    Whenever possible, clients and relays should use the list of
    advertised protocols instead of version numbers.  Version numbers
@@ -198,31 +200,40 @@ Status: Open
          0.2.4.19.  Includes support for CREATE2 and CREATED2 and
          EXTEND2 and EXTENDED2.
 
-5.3. "HSMid"
+5.4. "HSIntro"
 
-   The "HSMid" protocols are those that handle introduction points and
-   rendezvous points.
+   The "HSIntro" protocol handles introduction points.
 
-      "1" -- supports all features in Tor 0.2.4.19
+      "3" -- supports authentication as of proposal 121 in Tor
+             0.2.1.6-alpha.
 
-5.4. "DirCache"
+5.5. "HSRend"
 
-   The "DirCache" protocols are the set of documents available for
-   download from a directory cache via BEGIN_DIR, and the set of URLs
-   available to fetch them.  (This excludes URLs for hidden service
-   objects.)
+   The "HSRend" protocol handles rendezvous points.
 
-      "1" -- supports all features in Tor 0.2.4.19.
+      "1" -- supports all features in Tor 0.0.6.
+
+      "2" -- supports RENDEZVOUS2 cells of arbitrary length as long as they
+             have 20 bytes of cookie in Tor 0.2.9.1-alpha.
 
-5.5. "HSDir"
+5.6. "HSDir"
 
    The HSDir protocols are the set of hidden service document types
    that can be uploaded to, understood by, and downloaded from a tor
    relay, and the set of URLs available to fetch them.
 
+      "2" -- supports all features in Tor 0.2.0.10-alpha.
+
+5.7. "DirCache"
+
+   The "DirCache" protocols are the set of documents available for
+   download from a directory cache via BEGIN_DIR, and the set of URLs
+   available to fetch them.  (This excludes URLs for hidden service
+   objects.)
+
       "1" -- supports all features in Tor 0.2.4.19.
 
-5.6. "Desc"
+5.8. "Desc"
 
    Describes features present or absent in descriptors.
 
@@ -235,7 +246,7 @@ Status: Open
       "2" -- cross-signing with onion-keys, signing with ed25519
              identities.
 
-5.7. "Microdesc"
+5.9. "Microdesc"
 
    Describes features present or absent in microdescriptors.
 
@@ -247,7 +258,7 @@ Status: Open
 
       "2" -- consensus method 21 (adds ed25519 keys to microdescs).
 
-5.8. "Cons"
+5.10. "Cons"
 
    Describes features present or absent in consensus documents.
 
@@ -280,7 +291,7 @@ Status: Open
 
    Because all relays currently on the network are 0.2.4.19 or later, we
    can require 0.2.4.19, and use 0.2.4.19 as the minimal version so we
-   we don't need to do code archeology to determine how many
+   we don't need to do code archaeology to determine how many
    no-longer-relevant versions of each protocol once existed.
 
    Adding new protocol types is pretty cheap, given compression.
@@ -304,16 +315,18 @@ A.1.  Inferring missing proto lines.
 
 A.2. Initial required protocols
 
-   For clients we will Recommend and Require these.  For relays, we will
-   Recommend these:
+   For clients we will Recommend and Require these.
 
-        Cons=1-2 Desc=1-2 DirCache=1 HSDir=1 HSMid=1 Link=4
+        Cons=1-2 Desc=1-2 DirCache=1 HSDir=2 HSIntro=3 HSRend=1 Link=4
         LinkAuth=1 Microdesc=1-2 Relay=2
 
    For relays we will Require:
 
-        Cons=1 Desc=1 DirCache=1 HSDir=1 HSMid=1 Link=3-4
-        LinkAuth=1 icrodesc=1 Relay=1-2
+        Cons=1 Desc=1 DirCache=1 HSDir=2 HSIntro=3 HSRend=1 Link=3-4
+        LinkAuth=1 Microdesc=1 Relay=1-2
+
+   For relays, we will additionally Recommend all protocols which we
+   recommend for clients.
 
 A.3. Example integration with other open proposals
 
diff --git a/proposals/272-valid-and-running-by-default.txt b/proposals/272-valid-and-running-by-default.txt
index 7e14b6b..473d92b 100644
--- a/proposals/272-valid-and-running-by-default.txt
+++ b/proposals/272-valid-and-running-by-default.txt
@@ -2,7 +2,8 @@ Filename: 272-valid-and-running-by-default.txt
 Title: Listed routers should be Valid, Running, and treated as such
 Created: 26 Aug 2016
 Author: Nick Mathewson
-Status: Open
+Status: Finished
+Implemented-In: 0.2.9.3-alpha, 0.2.9.4-alpha
 
 1. Introduction and proposal.
 
diff --git a/proposals/273-exit-relay-pinning.txt b/proposals/273-exit-relay-pinning.txt
new file mode 100644
index 0000000..91c3763
--- /dev/null
+++ b/proposals/273-exit-relay-pinning.txt
@@ -0,0 +1,223 @@
+Filename: 273-exit-relay-pinning.txt
+Title: Exit relay pinning for web services
+Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster
+Created: 2016-09-22
+Status: Draft
+Target: n/a
+
+0. Overview
+
+   To mitigate the harm caused by malicious exit relays, this proposal
+   presents a novel scheme -- exit relay pinning -- to allow web sites
+   to express that Tor connections should preferably originate from a
+   set of predefined exit relays.  This proposal is currently in draft
+   state.  Any feedback is appreciated.
+
+1. Motivation
+
+   Malicious exit relays are increasingly becoming a problem.  We have
+   been witnessing numerous opportunistic attacks, but also highly
+   sophisticated, targeted attacks that are financially motivated.  So
+   far, we have been looking for malicious exit relays using active
+   probing and a number of heuristics, but since it is inexpensive to
+   keep setting up new exit relays, we are facing an uphill battle.
+
+   Similar to the now-obsolete concept of exit enclaves, this proposal
+   enables web services to express that Tor clients should prefer a
+   predefined set of exit relays when connecting to the service.  We
+   encourage sensitive sites to set up their own exit relays and have
+   Tor clients prefer these relays, thus greatly mitigating the risk of
+   man-in-the-middle attacks.
+
+2. Design
+
+2.1 Overview
+
+   A simple analogy helps in explaining the concept behind exit relay
+   pinning: HTTP Public Key Pinning (HPKP) allows web servers to express
+   that browsers should pin certificates for a given time interval.
+   Similarly, exit relay pinning (ERP) allows web servers to express
+   that Tor Browser should prefer a predefined set of exit relays.  This
+   makes it harder for malicious exit relays to be selected as last hop
+   for a given website.
+
+   Web servers advertise support for ERP in a new HTTP header that
+   points to an ERP policy.  This policy contains one or more exit
+   relays, and is signed by the respective relay's master identity key.
+   Once Tor Browser obtained a website's ERP policy, it will try to
+   select the site's preferred exit relays for subsequent connections.
+   The following subsections discuss this mechanism in greater detail.
+
+2.2 Exit relay pinning header
+
+   Web servers support ERP by advertising it in the "Tor-Exit-Pins" HTTP
+   header.  The header contains two directives, "url" and "max-age":
+
+     Tor-Exit-Pins: url="https://example.com/pins.txt"; max-age=2678400
+
+   The "url" directive points to the full policy, which MUST be HTTPS.
+   Tor Browser MUST NOT fetch the policy if it is not reachable over
+   HTTPS.  Also, Tor Browser MUST abort the ERP procedure if the HTTPS
+   certificate is not signed by a trusted authority.  The "max-age"
+   directive determines the time in seconds for how long Tor Browser
+   SHOULD cache the ERP policy.
+
+   After seeing a Tor-Exit-Pins header in an HTTP response, Tor Browser
+   MUST fetch and interpret the policy unless it already has it cached
+   and the cached policy has not yet expired.
+
+2.3 Exit relay pinning policy
+
+   An exit relay pinning policy MUST be formatted in JSON.  The root
+   element is called "erp-policy" and it points to a list of pinned exit
+   relays.  Each list element MUST contain two elements, "fingerprint"
+   and "signature".  The "fingerprint" element points to the
+   hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g.,
+   9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645.  The "signature" element
+   points to an Ed25519 signature, uppercase and hex-encoded.  The
+   following JSON shows a conceptual example:
+
+   {
+     "erp-policy": [
+       "start-policy",
+       {
+         "fingerprint": Fpr1,
+         "signature": Sig_K1("erp-signature" || "example.com" || Fpr1)
+       },
+       {
+         "fingerprint": Fpr2,
+         "signature": Sig_K2("erp-signature" || "example.com" || Fpr2)
+       },
+       ...
+       {
+         "fingerprint": Fprn,
+         "signature": Sig_Kn("erp-signature" || "example.com" || Fprn)
+       },
+       "end-policy"
+     ]
+   }
+
+   Fpr refers to a relay's fingerprint as discussed above.  In the
+   signature, K refers to a relay's master private identity key.  The ||
+   operator refers to string concatenation, i.e., "foo" || "bar" results
+   in "foobar".  "erp-signature" is a constant and denotes the purpose
+   of the signature.  "start-policy" and "end-policy" are both constants
+   and meant to prevent an adversary from serving a client only a
+   partial list of pins.
+
+   The signatures over fingerprint and domain are necessary to prove
+   that an exit relay agrees to being pinned.  The website's domain --
+   in this case example.com -- is part of the signature, so third
+   parties such as evil.com cannot coerce exit relays they don't own to
+   serve as their pinned exit relays.
+
+   After having fetched an ERP policy, Tor Browser MUST first verify
+   that the two constants "start-policy" and "end-policy" are present,
+   and then validate the signature over all list elements.  If any
+   element does not validate, Tor Browser MUST abort the ERP procedure.
+
+   If an ERP policy contains more than one exit relay, Tor Browser MUST
+   select one at random, weighted by its bandwidth.  That way, we can
+   balance load across all pinned exit relays.
+
+   Tor Browser could enforce the mapping from domain to exit relay by
+   adding the following directive to its configuration file:
+
+     MapAddress example.com example.com.Fpr_n.exit
+
+2.4 Defending against malicious websites
+
+   The purpose of exit relay pinning is to protect a website's users
+   from malicious exit relays.  We must further protect the same users
+   from the website, however, because it could abuse ERP to reduce a
+   user's anonymity set.  The website could group users into
+   arbitrarily-sized buckets by serving them different ERP policies on
+   their first visit.  For example, the first Tor user could be pinned
+   to exit relay A, the second user could be pinned to exit relay B,
+   etc.  This would allow the website to link together the sessions of
+   anonymous users.
+
+   We cannot prevent websites from serving client-specific policies, but
+   we can detect it by having Tor Browser fetch a website's ERP policy
+   over multiple independent exit relays.  If the policies are not
+   identical, Tor Browser MUST ignore the ERP policies.
+
+   If Tor Browser would attempt to fetch the ERP policy over n circuits
+   as quickly as possible, the website would receive n connections
+   within a narrow time interval, suggesting that all these connections
+   originated from the same client.  To impede such time-based
+   correlation attacks, Tor Browser MUST wait for a randomly determined
+   time span before fetching the ERP policy.  Tor Browser SHOULD
+   randomly sample a delay from an exponential distribution.  The
+   disadvantage of this defence is that it can take a while until Tor
+   Browser knows that it can trust an ERP policy.
+
+2.5 Design trade-offs
+
+   We now briefly discuss alternative design decisions, and why we
+   defined ERP the way we did.
+
+   Instead of having a web server *tell* Tor Browser about pinned exit
+   relays, we could have Tor Browser *ask* the web server, e.g., by
+   making it fetch a predefined URL, similar to robots.txt.  We believe
+   that this would involve too much overhead because only a tiny
+   fraction of sites that Tor users visit will have an ERP policy.
+
+   ERP implies that adversaries get to learn all the exit relays from
+   which all users of a pinned site come from.  These exit relays could
+   then become a target for traffic analysis or compromise.  Therefore,
+   websites that pin exit relays SHOULD have a proper HTTPS setup and
+   host their exit relays topologically close to the content servers, to
+   mitigate the threat of network-level adversaries.
+
+   It's possible to work around the bootstrapping problem (i.e., the
+   very first website visit cannot use pinned exits) by having an
+   infrastructure that allows us to pin exits out-of-band, e.g., by
+   hard-coding them in Tor Browser, or by providing a lookup service
+   prior to connecting to a site, but the additional complexity does not
+   seem to justify the added security or reduced overhead.
+
+2.6 Open questions
+
+   o How should we deal with selective DoS or otherwise unavailable exit
+     relays?  That is, what if an adversary takes offline pinned exit
+     relays?  Should Tor Browser give up, or fall back to non-pinned
+     exit relays that are potentially malicious?  Should we give site
+     operators an option to express a fallback if they care more about
+     availability than security?
+
+   o Are there any aspects that are unnecessarily tricky to implement in
+     Tor Browser?  If so, let's figure out how to make it easier to
+     build.
+
+   o Is a domain-level pinning granularity sufficient?
+
+   o Should we use the Ed25519 master or signing key?
+
+   o Can cached ERP policies survive a Tor Browser restart?  After all,
+     we are not supposed to write to disk, and ERP policies are
+     basically like a browsing history.
+
+   o Should we have some notion of "freshness" in an ERP policy?  The
+     problem is that an adversary could save my ERP policy for
+     example.com, and if I ever give up example.com, the adversary could
+     register it, and use my relays for pinning.  This could easily be
+     mitigated by rotating my relay identity keys, and might not be that
+     big a problem.
+
+   o Should we support non-HTTP services?  For example, do we want to
+     support, say, SSH?  And if so, how would we go about it?
+
+   o HPKP also defines a "report-uri" directive to which errors should
+     be reported.  Do we want something similar, so site operators can
+     detect issues such as attempted DoS attacks?
+
+   o It is wasteful to send a 60-70 byte header to all browsers while
+     only a tiny fraction of them will want it.  Web servers could send
+     the header only to IP addresses that run an exit relay, but that
+     adds quite a bit of extra complexity.
+
+   o We currently defend against malicious websites by fetching the ERP
+     policy over several exit relays, spread over time.  In doing so, we
+     are making assumptions on the number of visits the website sees.
+     Is there a better solution that isn't significantly more complex?