Re: xxx-draft-spec-for-TLS-normalization.txt

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

> Filename: xxx-draft-spec-for-TLS-normalization.txt
> Title: Draft spec for TLS certificate and handshake normalization
> Author: Jacob Appelbaum
> Created: 24-Jan-2011
> Status: Draft
>
>
>         Draft spec for TLS certificate and handshake normalization
>
>
>                                     Overview
>
> Scope
>
> This is a document that proposes improvements to problems with Tor's
> current TLS (Transport Layer Security) certificates and handshake that will
> reduce the distinguishability of Tor traffic from other encrypted traffic that
> uses TLS.  It also addresses some of the possible fingerprinting attacks
> possible against the current Tor TLS protocol setup process.
>
> Motivation and history
>
> Censorship is an arms race and this is a step forward in the defense
> of Tor.  This proposal outlines ideas to make it more difficult to
> fingerprint and block Tor traffic.
>
> Goals
>
> This proposal intends to normalize or remove easy-to-predict or static
> values in the Tor TLS certificates and with the Tor TLS setup process.
> These values can be used as criteria for the automated classification of
> encrypted traffic as Tor traffic. Network observers should not be able
> to trivially detect Tor merely by receiving or observing the certificate
> used or advertised by a Tor relay. I also propose the creation of
> a hard-to-detect covert channel through which a server can signal that it
> supports the third version ("V3") of the Tor handshake protocol.

This last bit might or might not be needed; let's see how stuff looks
after my v3 protocol proposal is more discussed.


 [...]
> Certificate Issues
>
> The CN or commonName ASN1 field
>
> Tor generates certificates with a predictable commonName field; the
> field is within a given range of values that is specific to Tor.
> Additionally, the generated host names have other undesirable properties.
> The host names typically do not resolve in the DNS because the domain
> names referred to are generated at random.

Also, when they do resolve, they do not resolve to any IP that the
certificate was served from.  Also, they're all .net.

 [...]
> I propose that the commonName field be generated to match a specific property
> of the server in question. It is reasonable to set the commonName element to
> match either the hostname of the relay, the detected IP address of the relay,
> or for the relay operator to override certificate generation entirely by
> loading a custom certificate.   For custom certificates, see the Custom
> Certificates section.
>
> I propose that the value for the commonName field be populated with the
> fully qualified host name as detected by reverse and forward resolution of the
> IP address of the relay. If the host name is in the DNS, this host name should
> be set as the common name. When forward and reverse DNS is not available, I
> propose that the IP address alone be used.

I'm not sure that an IP address is better than a random hostname.  Do
any CAs issue certs where the CN is an IP address?  Do many
self-signed certificates actually look that way?

If the answers are "no" and "not many", then we'll probably be better
off with randomly generated hostnames when we can't find a real
hostname to use.

> The commonName field for the issuer should be set to known issuer names,
> random words or omitted entirely.

There are two certificate profiles to imitate here: self-signed and
CA-issued.  For self-signed ones, both DNs typically match, I think.
This is worth checking too

 [...]
> Certificate serial numbers
>
> Currently our generated certificate serial number is set to the of number of
> seconds since the epoch at the time of the certificate's creation. I propose
> that we should ensure that our serial numbers are un-related to the epoch,
> since the generation methods are potentially recognizable as Tor-related.
> Instead, I propose that we use a randomly generated number that is
> subsequently hashed with SHA-512 and then truncated. The serial number
> should be similar in bit width to commonly found certificate serial numbers
> in the wild.

I'd want to back off here to see what certificates look like in the
wild.  Do they look random?  Do they look like timestamps?  Do they
increase sequentially?  Are they typically small for self-signed
certificates?

Also, taking a random number then computing its hash is redundant: if
it's random, just use it.

[...]
> Certificate dating and validity issues
>
> TLS certificates found in the wild are generally found to be long-lived;
> they are frequently old and often even expired. The current Tor certificate
> validity time is a very small time window starting at generation time and
> ending shortly thereafter, as defined in or.h by MAX_SSL_KEY_LIFETIME
> (2*60*60).
>
> I propose that the certificate validity time length is extended to a period of
> twelve Earth months, possibly with a small random skew to be determined by the
> implementer. Tor should randomly set the start date in the past or some
> currently unspecified window of time before the current date. This would
> more closely track the typical distribution of non-Tor TLS certificate
> expiration times.
>
> The certificate values, such as expiration, should not be used for anything
> relating to security; for example, if the OR presents an expired TLS
> certificate, this does not imply that the client should terminate the
> connection (as would be appropriate for an ordinary TLS implementation).

Hm.  Tor currently *does* check validAfter and validUntil times on
certificates.  Also, we *do* want a way to say "do not treat this cert
as valid forever" as a way to limit the impact of a key compromise.

[...]
> Problematic Diffie–Hellman parameters

We should get more data; right now, it seems that it's okay to use the
default DH parameter used by apache's mod_ssl, since it's very
frequently used in the wild.  We should only use randomly DH
parameters of some length P if it is in fact the case that such
parameters are not infrequent in the wild.

 [...]
>
> Practical key size
>
> Currently we use 1024-bit RSA keys. I propose that we increase the RSA key size
> to 1280 or to 2048 as an additional channel to signal support for the V3
> handshake setup. 2048 is likely a more common key size in certificates today
> and also provides a reasonable security boost with regard to key security
> properties.

Possibly; we should get data on this before we guess.  Also, as we
start to support longer sizes, we may want a way to advertise "maximum
allowed keysize" in the consensus to keep some wiseguy from making a
16384-bit key as a DOS attack.

> The implementer should choose a key size that is common and meaningfully above
> 1024 bits.
>
> Possible future filtering nightmares
>
> At some point it may cost effective or politically feasible for a network
> filter to simply block all signed or unsigned certificates without a known
> valid CA trust chain.

There's no such thing as an unsigned certificate; I think you mean
"self-signed."

-- 
Nick Mathewson