[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

Jacob Appelbaum <jacob@xxxxxxxxxxxxx> writes:

> I've re-worded and added some feedback from Tom and others to this
> draft. If anyone has any further comments before this becomes a numbered
> proposal - please reply on or-dev rather than privately as I'd like to
> keep the thread going in the open.
> All the best,
> Jake

As far as the certificate fields [1], the key size [2] and the
certificate time length are concerned, I'm wondering if it would be
worth it using the EFF's SSL Observatory data [3] to figure out the most
conservative values to use (and in the case of cert. fields, which
fields are actually usually used in the real world).

Mansour Moufid <mansourmoufid@xxxxxxxxx> writes:

>> As a security precaution, care must be taken to ensure that we do not generate
>> weak primes or known filtered primes. Both weak and filtered primes will
>> undermine the TLS connection security properties. OpenSSH solves this issue
>> dynamically in RFC 4419 [2] and may provide a solution that works reasonably
>> well for Tor. More research in this area including Miller-Rabin primality tests
>> will need to be analyzed and probably added to Tor.
>RFC 4419 suggests the Miller-Rabin test because it is efficient and
>well-known. Perhaps Tor could use the AKS primality test, which is
>also efficient, and deterministic.

The problem with AKS - and the reason it's not used in real life
applications - is it's terrible performance when in contrast with all
the other probabilistic primality tests [4].

[1]: Like you said, one could claim that the current Tor TLS
certificates could be fingerprinted by their empty O/L/ST/C/OU fields.

[2]: By the way, the key size upgrade (and the addition of more
ciphersuites) is also planned as part of the Tor ciphersuite migration.


[4]: Check out "An Implementation of the AKS Primality Test" from
Robert G. Salembier and Paul Southerington, for example.