r16479@catbus: nickm | 2007-11-06 18:10:02 -0500

 Add "Blocking resistant TLS certificate usage" as proposal 124.


svn:r12405

doc/spec/proposals/000-index.txt

@@ -27,7 +27,7 @@ Proposals by number:
 102  Dropping "opt" from the directory format [CLOSED]
 103  Splitting identity key from regularly used signing key [CLOSED]
 104  Long and Short Router Descriptors [CLOSED]
-105  Version negotiation for the Tor protocol [OPEN]
+105  Version negotiation for the Tor protocol [ACCEPTED]
 106  Checking fewer things during TLS handshakes [CLOSED]
 107  Uptime Sanity Checking [CLOSED]
 108  Base "Stable" Flag on Mean Time Between Failures [CLOSED]
@@ -46,12 +46,12 @@ Proposals by number:
 121  Hidden Service Authentication [OPEN]
 122  Network status entries need a new Unnamed flag [CLOSED]
 123  Naming authorities automatically create bindings [OPEN]
+124  Blocking resistant TLS certificate usage [ACCEPTED]
 
 
 Proposals by status:
 
  OPEN:
-   105  Version negotiation for the Tor protocol
    110  Avoiding infinite length circuits
    113  Simplifying directory authority administration
    114  Distributed Storage for Tor Hidden Service Descriptors
@@ -62,6 +62,8 @@ Proposals by status:
    121  Hidden Service Authentication
    123  Naming authorities automatically create bindings
  ACCEPTED:
+   105  Version negotiation for the Tor protocol
+   124  Blocking resistant TLS certificate usage
  NEEDS-RESEARCH:
    118  Advertising multiple ORPorts at once
  META:

doc/spec/proposals/124-tls-certificates.txt

@@ -0,0 +1,315 @@
+Filename: 124-tls-certificates.txt
+Title: Blocking resistant TLS certificate usage
+Version: $Revision$
+Last-Modified: $Date$
+Author: Steven J. Murdoch
+Created: 2007-10-25
+Status: Accepted
+
+Overview:
+
+  To be less distinguishable from HTTPS web browsing, only Tor servers should
+  present TLS certificates. This should be done whilst maintaining backwards
+  compatibility with Tor nodes which present and expect client certificates, and
+  while preserving existing security properties. This specification describes
+  the negotiation protocol, what certificates should be presented during the TLS
+  negotiation, and how to move the client authentication within the encrypted
+  tunnel.
+
+Motivation:
+
+  In Tor's current TLS [1] handshake, both client and server present a
+  two-certificate chain. Since TLS performs authentication prior to establishing
+  the encrypted tunnel, the contents of these certificates are visible to an
+  eavesdropper. In contrast, during normal HTTPS web browsing, the server
+  presents a single certificate, signed by a root CA and the client presents no
+  certificate. Hence it is possible to distinguish Tor from HTTP by identifying
+  this pattern.
+
+  To resist blocking based on traffic identification, Tor should behave as close
+  to HTTPS as possible, i.e. servers should offer a single certificate and not
+  request a client certificate; clients should present no certificate. This
+  presents two difficulties: clients are no longer authenticated and servers are
+  authenticated by the connection key, rather than identity key. The link
+  protocol must thus be modified to preserve the old security semantics.
+
+  Finally, in order to maintain backwards compatibility, servers must correctly
+  identify whether the client supports the modified certificate handling. This
+  is achieved by modifying the cipher suites that clients advertise support
+  for. These cipher suites are selected to be similar to those chosen by web
+  browsers, in order to resist blocking based on client hello.
+
+Terminology:
+
+  Initiator: OP or OR which initiates a TLS connection ("client" in TLS
+   terminology)
+  
+  Responder: OR which receives an incoming TLS connection ("server" in TLS
+   terminology) 
+
+Version negotiation and cipher suite selection:
+
+  In the modified TLS handshake, the responder does not request a certificate
+  from the initiator. This request would normally occur immediately after the
+  responder receives the client hello (the first message in a TLS handshake) and
+  so the responder must decide whether to request a certificate based only on
+  the information in the client hello. This is achieved by examining the cipher
+  suites in the client hello.
+
+   List 1: cipher suites lists offered by version 0/1 Tor
+
+   From src/common/tortls.c, revision 12086:
+    TLS1_TXT_DHE_RSA_WITH_AES_128_SHA 
+    TLS1_TXT_DHE_RSA_WITH_AES_128_SHA : SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
+    SSL3_TXT_EDH_RSA_DES_192_CBC3_SHA
+
+ Client hello sent by initiator:
+
+  Initiators supporting version 2 of the Tor connection protocol MUST
+  offer a different cipher suite list from those sent by pre-version 2
+  Tors, contained in List 1. To maintain compatibility with older Tor
+  versions and common browsers, the cipher suite list MUST include
+  support for:
+
+   TLS_DHE_RSA_WITH_AES_256_CBC_SHA
+   TLS_DHE_RSA_WITH_AES_128_CBC_SHA
+   SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
+   SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
+
+ Client hello received by responder/server hello sent by responder:
+
+  Responders supporting version 2 of the Tor connection protocol should compare
+  the cipher suite list in the client hello with those in List 1. If it matches
+  any in the list then the responder should assume that the initiatior supports
+  version 1, and should thus should maintain the version 1 behavior, i.e. send a
+  two-certificate chain, request a client certificate and do not send or expect
+  a VERSIONS cell [2].
+
+  Otherwise, the responder should assume version 2 behavior and select a cipher
+  suite following TLS [1] behavior, i.e. select the first entry from the client
+  hello cipher list which is acceptable. Responders MUST NOT select any suite
+  that lacks ephemeral keys, or whose symmetric keys are less then KEY_LEN bits,
+  or whose digests are less than HASH_LEN bits. Implementations SHOULD NOT
+  allow other SSLv3 ciphersuites. 
+
+  Should no mutually acceptable cipher suite be found, the connection MUST be
+  closed.
+
+  If the responder is implementing version 2 of the connection protocol it
+  SHOULD send a server certificate with random contents. The organizationName
+  field MUST NOT be "Tor", "TOR" or "t o r".
+
+ Server certificate received by initiator:
+
+  If the server certificate has an organizationName of "Tor", "TOR" or "t o r",
+  the initiator should assume that the responder does not support version 2 of
+  the connection protocol. In which case the initiator should respond following
+  version 1, i.e. send a two-certificate client chain and do not send or expect
+  a VERSIONS cell.
+
+  [SJM: We could also use the fact that a client certificate request was sent]
+  
+  If the server hello contains a ciphersuite which does not comply with the key
+  length requirements above, even if it was one offered in the client hello, the
+  connection MUST be closed. This will only occur if the responder is not a Tor
+  server.
+
+ Backward compatibility:
+
+  v1 Initiator, v1 Responder: No change
+  v1 Initiator, v2 Responder: Responder detects v1 initiator by client hello
+  v2 Initiator, v1 Responder: Responder accepts v2 client hello. Initiator
+   detects v1 server certificate and continues with v1 protocol
+  v2 Initiator, v2 Responder: Responder accepts v2 client hello. Initiator
+   detects v2 server certificate and continues with v2 protocol.
+
+ Additional link authentication process:
+
+  Following VERSION and NETINFO negotiation, both responder and
+  initiator MUST send a certification chain in a CERT cell. If one
+  party does not have a certificate, the CERT cell MUST still be sent,
+  but with a length of zero.
+
+  A CERT cell is a variable length cell, of the format
+        CircID                                [2 bytes]
+        Command                               [1 byte]
+        Length                                [2 bytes]
+        Payload                               [<length> bytes]
+
+  CircID MUST set to be 0x0000
+  Command is [SJM: TODO]
+  Length is the length of the payload
+  Payload contains 0 or more certificates, each is of the format:
+        Cert_Length  [2 bytes]
+        Certificate  [<cert_length> bytes]
+
+  Each certificate MUST sign the one prececeding it. The initator MUST
+  place its connection certificate first; the responder, having
+  already sent its connection certificate as part of the TLS handshake
+  MUST place its identity certificate first.
+
+  Initiators who send a CERT cell MUST follow that with an LINK_AUTH
+  cell to prove that they posess the corresponding private key.  
+
+  A LINK_AUTH cell is fixed-lenth, of the format:
+         CircID                                [2 bytes]
+         Command                               [1 byte]
+         Length                                [2 bytes]
+         Payload (padded with 0 bytes)         [PAYLOAD_LEN - 2 bytes]
+
+  CircID MUST set to be 0x0000
+  Command is [SJM: TODO]
+  Length is the valid portion of the payload
+  Payload is of the format:
+         Signature version                     [1 byte]
+         Signature                             [<length> - 1 bytes]
+         Padding                               [PAYLOAD_LEN - <length> - 2 bytes]
+
+  Signature version: Identifies the type of signature, currently 0x00
+  Signature: Digital signature under the initiator's connection key of the
+   following item, in PKCS #1 block type 1 [3] format:
+
+    HMAC-SHA1, using the TLS master secret as key, of the
+    following elements concatenated:
+     - The signature version (0x00)
+     - The NUL terminated ASCII string: "Tor initiator certificate verification"
+     - client_random, as sent in the Client Hello
+     - server_random, as sent in the Server Hello
+     - SHA-1 hash of the initiator connection certificate
+     - SHA-1 hash of the responder connection certificate
+
+  Security checks:
+
+    - Before sending a LINK_AUTH cell, a node MUST ensure that the TLS
+      connection is authenticated by the responder key.
+    - For the handshake to have succeeded, the initiator MUST confirm:
+       - That the TLS handshake was authenticated by the 
+         responder connection key
+       - That the responder connection key was signed by the first
+         certificate in the CERT cell
+       - That each certificate in the CERT cell was signed by the
+         following certificate, with the exception of the last
+       - That the last certificate in the CERT cell is the expected
+         identity certificate for the node being connected to
+    - For the handshake to have succeeded, the responder MUST confirm
+      either:
+       A) - A zero length CERT cell was sent and no LINK_AUTH cell was
+            sent
+          In which case the responder shall treat the identity of the
+          initiator as unknown
+        or
+       B) - That the LINK_AUTH MAC contains a signature by the first
+            certificate in the CERT cell
+          - That the MAC signed matches the expected value
+          - That each certificate in the CERT cell was signed by the
+            following certificate, with the exception of the last
+          In which case the responder shall treat the identity of the
+          initiator as that of the last certificate in the CERT cell
+
+  Protocol summary:
+
+  1. I(nitiator) <-> R(esponder): TLS handshake, including responder
+                               authentication under connection certificate R_c
+  2. I <->: VERSION and NETINFO negotiation
+  3. R -> I: CERT (Responder identity certificate R_i (which signs R_c))
+  4. I -> R: CERT (Initiator connection certificate I_c, 
+                   Initiator identity certificate I_i (which signs I_c)
+  5. I -> R: LINK_AUTH (Signature, under I_c of HMAC-SHA1(master_secret,
+                    "Tor initiator certificate verification" ||
+                    client_random || server_random ||
+                    I_c hash || R_c hash)
+
+  Notes: I -> R doesn't need to wait for R_i before sending its own
+   messages (reduces round-trips).
+   Certificate hash is calculated like identity hash in CREATE cells.
+   Initiator signature is calculated in a similar way to Certificate
+   Verify messages in TLS 1.1 (RFC4346, Sections 7.4.8 and 4.7).
+   If I is an OP, a zero length certificate chain may be sent in step 4;
+   In which case, step 5 is not performed
+
+  Rationale: 
+
+  - Version and netinfo negotiation before authentication: The version cell needs
+   to come before before the rest of the protocol, since we may choose to alter
+   the rest at some later point, e.g switch to a different MAC/signature scheme.
+   It is useful to keep the NETINFO and VERSION cells close to each other, since
+   the time between them is used to check if there is a delay-attack. Still, a
+   server might want to not act on NETINFO data from an initiator until the
+   authentication is complete.
+
+Appendix A: Cipher suite choices
+
+  This specification intentionally does not put any constraints on the
+  TLS ciphersuite lists presented by clients, other than a minimum
+  required for compatibility. However, to maximize blocking
+  resistance, ciphersuite lists should be carefully selected.
+
+   Recommended client ciphersuite list
+
+     Source: http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslproto.h
+
+     0xc00a: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA  
+     0xc014: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 
+     0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA 
+     0x0038: TLS_DHE_DSS_WITH_AES_256_CBC_SHA
+     0xc00f: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA 
+     0xc005: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA 
+     0x0035: TLS_RSA_WITH_AES_256_CBC_SHA
+     0xc007: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA 
+     0xc009: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA 
+     0xc011: TLS_ECDHE_RSA_WITH_RC4_128_SHA
+     0xc013: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 
+     0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
+     0x0032: TLS_DHE_DSS_WITH_AES_128_CBC_SHA 
+     0xc00c: TLS_ECDH_RSA_WITH_RC4_128_SHA
+     0xc00e: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
+     0xc002: TLS_ECDH_ECDSA_WITH_RC4_128_SHA  
+     0xc004: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA 
+     0x0004: SSL_RSA_WITH_RC4_128_MD5 
+     0x0005: SSL_RSA_WITH_RC4_128_SHA 
+     0x002f: TLS_RSA_WITH_AES_128_CBC_SHA 
+     0xc008: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA 
+     0xc012: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
+     0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA  
+     0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA 
+     0xc00d: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA 
+     0xc003: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
+     0xfeff: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (168-bit Triple DES with RSA and a SHA1 MAC)
+     0x000a: SSL_RSA_WITH_3DES_EDE_CBC_SHA 
+
+     Order specified in:
+      http://lxr.mozilla.org/security/source/security/nss/lib/ssl/sslenum.c#47
+
+   Recommended options:
+      0x0000: Server Name Indication [4]
+      0x000a: Supported Elliptic Curves [5]
+      0x000b: Supported Point Formats [5]
+
+   Recommended compression:
+      0x00
+
+   Recommended server ciphersuite selection:
+
+     The responder should select the first entry in this list which is
+     listed in the client hello:
+
+     0x0039: TLS_DHE_RSA_WITH_AES_256_CBC_SHA  [ Common Firefox choice ]
+     0x0033: TLS_DHE_RSA_WITH_AES_128_CBC_SHA  [ Tor v1 default ] 
+     0x0016: SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA [ Tor v1 fallback ]
+     0x0013: SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA [ Valid IE option ]
+
+References:
+
+[1] The Transport Layer Security (TLS) Protocol, Version 1.1, RFC4346, IETF
+
+[2] Version negotiation for the Tor protocol, Tor proposal 105
+
+[3] B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1:
+    RSA Cryptography Specifications Version 1.5", RFC 2313,
+    March 1998.
+
+[4] TLS Extensions, RFC 3546
+
+[5] Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
+
+% <!-- Local IspellDict: american -->