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

[Jacob Appelbaum <jacob@xxxxxxxxxxxxx>]

On 01/27/2011 03:47 AM, George Kadianakis wrote:
> 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).

I've previously inquired with Seth (of the EFF) to see if he has any
ideas about these fields. Perhaps when he's had the time to look, he'll
reply to this thread?

> 
> 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].
> 

I guess that if we only generate p a single time at startup, it won't
matter too much.

> [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.
> 

Yes, I'm certain that it's possible. I'm unsure about the collateral damage.

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

Yes, that's part of the big picture. Doing the switch all at once seems
like a good idea.

> [3]:
> https://www.eff.org/files/downloaded-certificates.tar.lzma.torrent
> https://www.eff.org/files/csv-db-files.tar.lzma.torrent
> 

I'd like to run these queries on a live DB. I don't currently have a
machine to load these files where it won't take a century, so I'm going
to punt and see if Seth has any suggestions. If he doesn't, I'll find a
fast machine for some computing...

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

Thanks for the pointer and the feedback!

All the best,
Jake