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

Barry Leiba <barryleiba@computer.org> Fri, 27 April 2012 01:28 UTC

Return-Path: <barryleiba.mailing.lists@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355D811E8091 for <oauth@ietfa.amsl.com>; Thu, 26 Apr 2012 18:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level:
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akVRZb02NSvU for <oauth@ietfa.amsl.com>; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83B9811E8079 for <oauth@ietf.org>; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so146081ghb.31 for <oauth@ietf.org>; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=FQzcXV+V1ucw2FqX2XX6U9Chgs4v//EWvmdlVDV6+hc=; b=jEdnOh4TXNiH7yO76gFxGRBYfKCrq/BS/JGsJoYvcjJyU5D/9g0ECpsJpWdiSdr40F BOJAodrkoE3pyVUYaSkTGlaYq3DoifFsm002D0hH4IaLWoqDGEwml/ZS4gEMPeX+13IP kCnz5Bs7dQUz/6hseaHciOJksJ0xWl7+AdKw06eEhYRRGc63EnUc2+I30cZ5JDt4sIp6 pZugAumBe8e4AGz1m8d+bcX6brtW0makhWvuMDAZGlodRJ74FYI1PIufJV6MvpduIWWH 7DnnR6HjjjgCh1FLWt7UGe3fz1GuNosysG73Ki66xN5zTLuYgi2IFw+F4JUDikYJnwWU 50/A==
MIME-Version: 1.0
Received: by 10.236.185.10 with SMTP id t10mr8981755yhm.112.1335490100103; Thu, 26 Apr 2012 18:28:20 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.147.152.14 with HTTP; Thu, 26 Apr 2012 18:28:19 -0700 (PDT)
In-Reply-To: <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
References: <CALaySJLy6jpuPqxQXfKfpx0TpcK1gav1NtcTOoh+NOr11JSCbw@mail.gmail.com> <4F8DE789.4030704@mtcc.com> <CALaySJK1ej_HkP5Jz26XT-KjULirD2iFfVOpRkHgPZp-CbJCrg@mail.gmail.com> <4F957EA7.3060004@mtcc.com> <OF3ECF645E.478720A4-ON802579EA.002D0B13-802579EA.002D8D07@ie.ibm.com> <4F96A99F.7010303@mtcc.com> <85556C53-99DD-47A2-A0D5-2F86DD2B668F@oracle.com> <0CBAEB56DDB3A140BA8E8C124C04ECA2FFC41C@P3PWEX2MB008.ex2.secureserver.net> <580607FC-28EC-4BBA-8CBA-C63D2FA52C8E@oracle.com>
Date: Thu, 26 Apr 2012 21:28:19 -0400
X-Google-Sender-Auth: K2PlQI3ejfRdNd3PlbBZzY_QJZ0
Message-ID: <CAC4RtVAD3NVm8vcSNJvpYPU0meFh9tbN6dXqBS5XbHRKagCfwA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: oauth@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [OAUTH-WG] Shepherd review of draft-ietf-oauth-v2-threatmodel
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Apr 2012 01:28:21 -0000

Phil said...

> **However**  Editorially I feel strongly the comments fall outside the intended scope
> and purpose for this document. This document is about threats specifically related
> to the OAuth protocol.  It's intent is to go beyond security considerations to give
> implementers a feel for the issues the group has considered specific to the protocol.
>
> Michael's comments are directed at general trusted computing platform. And while I
> agree they are valid, they don't fit in this document.

I'll add one thing to this consideration:  while I agree that we can't
discuss every threat that one might encounter in a web services
environment, I think it's useful and important to discuss issues that
people are likely to think are addressed, mitigated, or solved by
OAuth, *even if we don't think that, and even if we know they're not
really OAuth issues.*

DKIM had a related problem (which I do NOT want to open up for
discussion here; I mention it only for comparison).  DKIM was often
oversold as being something that would "block spam" or "stop phishing
in its tracks."  It will do neither, though it's a tool to be used in
systems that aim at both.  Similarly, while OAuth solves a real
problem and is a good step, it will not *stop* impersonation attacks,
credential-theft attacks, and so on.  We all know that, but many
people who will read the OAuth spec will think it can do that.  The
threats document should be addressing that "overselling" problem[1],
and if that means highlighting a few things that we think should be
obvious, I'm in favour of it.

I think the things that Mike Thomas has bought up fall into that
category.  I'm sympathetic to the argument that this is a long
document, bordering on (or perhaps having crossed the border into)
"tl;dr" territory.  Perhaps there are other things that can be
trimmed.  But at this point, I've made a proposal to add a few
paragraphs, and mostly (not completely) gotten feedback from the
editors that my text is acceptable.  Mike has asked for one paragraph
to be added to that, and I think his proposal is reasonable.  If we go
with that set of additions, I think we'll address some of the
overselling problem, and I think the document will be better for it.

If the editors want to post my suggested addition here, they may do
so; yes, it was meant for a small group to iron out first, but the WG
will have to see and agree to it at some point anyway.  If the editors
want to trim a bit elsewhere in the document to make room, they may
also do that -- with the consent of the WG.  But let's please not get
hung up on this to the point of losing traction on the whole document.

And everyone please relax and not get hot or snarky: we're all trying
to make a better document, and calm discussion, rather than sarcasm
and hyperbole, is the best way to do that.  We're almost there.  We'll
get there soon.

Barry, document shepherd