Hello Eran, On Jan 15, 2010, at 4:41 PM, Eran Hammer-Lahav wrote:
> > On 1/15/10 7:58 AM, "John Kemp" <[email protected]> wrote: > >> When I look at what is possible in the offline world, I would ask - would you >> require that movie theatre tickets bought in advance were encrypted in >> transport between the person who bought the ticket and the receptionist at >> the >> cinema? What if the person drops her ticket and it's picked up by someone >> else? The risk of someone dropping his ticket is low, so we don't bother to >> secure it (of course, I haven't been to a city movie theatre in years so >> perhaps you need to show ID even to see a movie these days -- I hope not ;) >> Of >> course, the person who _does_ drop his ticket will be mad when he gets to the >> movie theatre, but probably not too mad. The system has worked quite well >> without any real security. We might add more security, but it would, even >> today, probably be hard to justify the cost. > > I don't think this is a fair comparison. Stealing a movie ticket is very > hard, and punishable but fines and prison time (potentially federal is > captured in transit via US Mail). The point is that the overall system makes the cost of providing any extra security not very worthwhile, as most thieves aren't that interested in stealing movie tickets, and most people don't lose their tickets! > On the other hand, capturing bearer tokens > while sitting at a Starbucks using nothing more than a laptop with a WiFi > card is trivial. Why would someone bother to sit and capture bearer tokens - what is the value of doing that, and what is the actual risk? In some cases, probably not that great... Imagine that we have an online movie bearer token - it's one-time use + replay-protected and gets delivered to the original requester after that entity has been authenticated (and is delivered over SSL). Now your thief has to grab that token as it is sent over the wire and somehow send it himself before the first request (by the lawfully-authorized viewer) is processed by the server! I think this is hard too - not impossible, but hard enough that for low-value cases, I simply wouldn't worry too much about encrypting that initial request (although of course, the movie stream itself would be DRMed!). > >> Yes, those things change over time, but having a sliding scale of security is >> a good thing, not a bad thing - and that is already allowed by OAuth today, >> (TLS/SSL+PLAINTEXT, RSA-SHA1, HMAC-SHA1, PLAINTEXT) and will continue even if >> you remove PLAINTEXT from the list. > > We are creating web standards, not just generic technologies. I don't want > to find *any* PLAINTEXT implementation on the web, but don't care if someone > uses it on their own private network. But if that's what they are doing, > they are free to drop TLS/SSL requirement anyway because they control the > environment. > > Since we are talking about one word, MUST vs. SHOULD, I think we should > start with MUST and continue having this discussion when we have more pieces > of the puzzle in place. I think you've raised a valid issue, but I don't yet hear any consensus about this change, or whether the suggested text actually does what we want. I hope you'll consider that (and perhaps wait a bit longer to make such a change). Cheers, - johnk _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
