At 11:21 AM -0400 8/26/2000, Jeff Kandt wrote:
>On or about 11:52 AM -0400 8/24/00, Arnold G. Reinhold wrote:
>>>The design goals: http://tipster.weblogs.com/designgoals
>>>The crypto protocol: http://tipster.weblogs.com/tipsterblock/
>>>
>>>Both of these are open to debate.
>>>
>>
>>First let me say something positive. I like your design goals. They
>>are reasonable and clear. I have a couple of quibbles, but they
>>are minor. On the other hand, I must say that I do not see how your
>>crypto protocol is justified by your design goals. I'd like to see
>>a justification for you protocol based on the design goals.
>
>What would that look like? A sentence or two after each goal which
>says "Tipster fulfills this goal by..."? I was thinking of doing
>that.
I'd like to see a sentence or three after each element in the
*protocol* describing which goal they are addressing, what type of
attack they are intended to prevent and how they prevent it. A
separate threat model would also be helpful.
>...
>
>
>
>>o The requirement of certificate cancellation seems to imply a
>>central server. That violates goal 7.
>
>Yes, goals 6 and 7 are in conflict here, I think. I'm not terribly
>happy with relying on a central registry, but I couldn't think of
>another way for an artist to cut off a server, given that the
>provider's URL may still be stamped on files which were created long
>ago.
>
>I judged that since revokation certificates can't be created by
>anyone who doesn't possess the private key, the worst trouble a
>malicious central registry could cause would be to _fail_ to
>propagate a revokation cert. Since this should be easy for the
>artist to discover, I thought this was a low risk.
As a practical matter there is a high likelihood that revocations
simply won't happen . Since your goal is to prevent artists from
being cheated, I would find this unacceptable. Again, I think there
are better ways.
>
>
>>o Why does every server have to sign each piece of content? Why do
>>you even care about the hash of the content? That seems to violate
>>goal 2.
>
>My goal #3, "difficult for thief/attacker to steal tips" should have
>added the word "successfully."
>
>While it's impossible to prevent someone from attaching their
>contact info to someone else's file, my goal with Tipster's
>signatures was to make such naughtiness easy to discover and
>prosecute.
>
>If the artist discovers one of his files posted somewhere with
>someone else's contact info on it, the signature makes it difficult
>for the persons who run the malicious server to deny that they were
>active participants. If the signature from the thief's server
>matches the key used to sign the pirated file, that's a pretty
>effective smoking gun. Not only did he sign the file, but he's
>running a server which uses that same key to collect payments.
I expect that phony servers would be set up in jurisdictions where
they will be difficult (and expensive) to pursue. They may also have
short lives -- take the money and run. Then start a new server, seed
phony content and do it again. In any case, if the fan knows the
artist's sig then a phony sever cannot provide the necessary cert to
collect money.
>
>And here's where we get into the trust issue. Despite goal 7,
>decentralization, I'm afraid lately I'm leaning towards a
>certificate authority model, maybe similar to SSL. Given the above
>threat model, all that is really needed is for the key to be signed
>by someone who has checked the artist's credentials as a legal
>entity, making sure they are someone who can be tracked down in
>meatspace by the cops and lawyers if they abuse their cert by using
>it to steal others' tips.
Artist and server certs have different needs. All artists require is
a binding to the band name. Servers need the tie to meatspace. You
can still avoid the centralization problem by allowing multiple CAs,
and other sources of trust for artist sigs.
>
>>o Goal 4 suggests that only information that will never change
>>should be included with content. Servers will come and go. All you
>>really need is the artist's URL. Why add more?
>
>Yes, an artist could maintain a single, stable URL. But most
>artists aren't technically savvy enough to administer their own
>server, any many are too low-budget to afford their own server,
>domain and Verisign/Thawte certificate. So they're going to have to
>delegate to others, and this is where I really want to be careful.
Servers and domain names do not have to be expensive. The is a lot
of competition in the hosting business. Domain names cost as little
as $8 these days, I'm told.
Cooperatives may be an alternative model. There is a whole legal
structure in the US that gives them a lot of protection. It might be
a worthwhile project to develop a musicians cooperative web site
hosting software package, along with a suitable draft legal
agreement. Such coops could also handle payment receipts,
eliminating any need for payment servers..
There is also the problem of how artists are going to hold their
secret keys. Keeping it on their Internet-connected computers is a
bad idea. You might want to look at cryptographic token technology
like iButton. You also need to think through bands with multiple
memebers who change over time. Who holds the key?
>
>
>[agr]I think one can design a much simpler system that meets your
>design goals. My suggestion would be ...
>
>This sounds very similar to another suggestion I got for a simpler
>system. The writer also suggested a system where the artists each
>register their own URL, except that he proposed delegating the trust
>issue to SSL.
>
>http://tipster.weblogs.com/discuss/msgReader$58
>
>A later enhancement used expiring server keys, as you suggest, to
>make revokation certs unnecessary, an idea I'll probably adopt.
>
>http://tipster.weblogs.com/discuss/msgReader$68
>
>Thanks very much for the feedback, Arnold. I'm still digging.
>Based on the comments I've gotten from you and others, I will be
>writing up some of the pros and cons of the various plans on my site
>and requesting another round of comment soon.
>
>May I quote/post your emails? (Or is there a web archive of these
>posts anywhere?)
Feel free to quote and/or post them.
Arnold Reinhold
