Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel

Eran Hammer <> Tue, 24 April 2012 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4236711E808F for <>; Tue, 24 Apr 2012 11:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yE-HHapgy674 for <>; Tue, 24 Apr 2012 11:05:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8D44B11E80C1 for <>; Tue, 24 Apr 2012 11:05:03 -0700 (PDT)
Received: from ([]) by with bizsmtp id 1u531j0070CJzpC01u53jx; Tue, 24 Apr 2012 11:05:03 -0700
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Tue, 24 Apr 2012 11:05:02 -0700
From: Eran Hammer <>
To: Derek Atkins <>
Thread-Topic: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
Thread-Index: AQHNIj0+r7KmwuXA4kSoc9MS46QExJaqQQHw
Date: Tue, 24 Apr 2012 18:05:02 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 24 Apr 2012 18:05:04 -0000

There is a lot of history on this thread.

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.

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

I don't care how this is resolved. At this point I don't mind the threat being added just to close the issue.


> -----Original Message-----
> From: Derek Atkins []
> Sent: Tuesday, April 24, 2012 10:11 AM
> To: Eran Hammer
> Cc:;
> Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-
> threatmodel
> Eran Hammer <> writes:
> > We've been kicking this can of silliness for months now because one
> > person refuses to move on even in the face of otherwise unanimous
> > consensus from the group.
> >
> > Chairs - Please take this ridiculous and never ending thread off list
> > and resolve it once and for all.
> Sure, I'll gladly stop the thread when the document is updated to actually
> mention all threats that someone has considered and brought to the group's
> attention.  That *is* the point of a threats document, after all.
> In a threats document nothing should be implicit or assumed -- the reader
> does not have the advantage of our group's knowledge of the space or
> operational guidance.  As a result, everything should be explicitly stated.
> Every threat that is brought to the attention of this gorup should be
> mentioned, explicitly, even if it's only a single sentence as part of a paragraph
> of "threats that fall outside the aforementioned assumptions"
> or "threats that have a simple workaround".
> -derek
> --
>        Derek Atkins                 617-623-3745
>        Computer and Internet Security Consultant