Eran Hammer <e...@hueniverse.com> writes:
> There is a lot of history on this thread.
I know. I have read it all. Frankly, I feel that Michael was treated
poorly by the members of this group.
> At the heart of it is a request from a working group member that the
> specification makes it clear that OAuth does not protect against
> malware and viruses, or other malicious software installed on the user
> device. During the first (or second, I can't recall) run of this
> debate, the chair *did* make a consensus call that the WG did not feel
> this was an OAuth specific threat. The chair's proposed resolution at
> the time was clearly too vague to close the issue and hence we are
> still arguing about it.
That's not exactly how I read the original request. One part I remember
clearly was more a question about user interface and "protecting" the
User<->AS request. I think this could've been handled by a simple
statement that "protecting a device or end-user user interface is out of
scope for OAUTH".
There was also an issue about handling bad players in the system (e.g. a
Bad Client player). As a security person I'm afraid I do have to agree
with Michael here, a threats document cannot say that to counteract a
bad player you need to have a good player. You need to either say that
the protocol does not protect against a bad player, or you need to say
how to protect against a bad player. There is nothing wrong saying that
it doesn't protect against a bad player, but writing it off will
definitely make you look less credible.
> Adding the requested threat will make the document look less credible
> for stating the obvious. I do not agree that any threat mentioned
> should be listed. At some point, and we're almost there, you lose the
> forest for the trees.
And it looks credible to imply that OAUTH protects against all attacks
including the kitchen-sink attack? Maybe it is obvious to you, but
you've been knee deep in the protocol for years. It is not necessarily
obvious to the next person who reads the drafts. Being honest about
what OAUTH does (and more importantly does NOT) do is more credible than
ignoring what might be obvious to some but not obvious to others.
> And BTW, as a response to Michael's original comment, I have requested
> that the threat of earthquakes will also be listed under UX
> considerations to prevent a user from clicking 'Approve' during an
> earthquake if it is too close to the 'Deny' button. Is my threat,
> which is clearly valid (no matter how unlikely), going to be added as
> well? Please don't, but I hope you see my point here. Many bad things
> can happen to you while using OAuth.
And you're worried about sounding credible by talking about bad players
and being explicit about the scope of OAUTH protection on a client
device? Following your suggestion, ad absurdium, why not talk about the
threat of a meteor shower? Seriously, yes, there is a line that has to
be drawn; clearly *I* needed to be more explicit about that. Yes, of
course the threat has to actually apply, but dismissing a threat out of
hand because you don't like it or you feel it will make you look less
"credible" only makes you look less credible.
> I don't care how this is resolved. At this point I don't mind the
> threat being added just to close the issue.
Sold. Thank you, Eran.
> EH
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
