Re: Hooking nym to wikipedia

[Jason Holt <jason@xxxxxxxxxxxx>]

More thoughts regarding the tokens vs. certs decision, and also multi-use:

* Client certs are a pain to turn on and off.  If you select "ask me every 
time" before sending a client cert, you have to click half a dozen "OK"s per 
page.  (This could be mitigated by having Wikipedia only use the SSL server 
for edits, since they're not blocking article viewing anyway, just editing.) 
If you tell the browser to send the certificate automatically and then forget 
about it, other SSL sites can silently request it, which is particularly bad 
if you're not using tor just then.

* Using tokens directly at site login time avoids the client cert hassles. 
However, evil web servers could then collect tokens (nyms) for use at other 
sites, suggesting that each server should run its own token server.  But now 
each server has a (potentially short) list of client IPs, whereas a 
centralized token server would provide better concealment.  Obviously, if 
wikipedia is the only site that ever bothers to use nym, this is a moot point.

* Lack of forward secrecy is indeed an issue, since our metaphorical Chinese 
dissident must keep around her cert to continue using it, which if discovered 
links her with all her past activities.  This is a problem even if Wikipedia 
maps each client cert to a particular random value for public display, since 
the attackers can simply use the stolen cert to make an edit on wikipedia and 
then check to see if the identifier comes up the same.

If Wikipedia generates a new random ID for each edit, then attackers have to 
access Wikipedia internals to map the IDs back to the cert, but then, so do 
Wikipedia admins when they want to assess a user's pattern of (bad) behavior. 
Note that SSL does not (IIRC) encrypt certificates, so a passive network 
eavesdropper can associate client certs with the random IDs.  (Do the 
ephemeral modes hide the certs?)

A related approach that thwarts the network eavesdropper would be to issue a 
series of certificates which expire one per interval (hour/day/whatever, 
trading privacy against the hassle of managing lots of certs).  Then our 
dissident uses each cert in turn, securely deleting it after it expires.  The 
CA keeps a list recording all the certs issued to the same user, and when 
Wikipedia wishes to ban a user, the CA revokes all the unexpired certs for 
that user.  The CA also securely deletes expired certs from its lists, so that 
if compromised, it has merely the same list of certs found on the client 
machine, and is likewise devoid of any reference to certs used in prior 
transactions.

Of course, there are nifty cryptographic solutions to the problem of revoking 
repeat offenders without linking activities of good users.  Private 
Credentials and Idemix are the two best known examples, but both are 
complicated and patent-ridden.

							-J