Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt

William Denniss <wdenniss@google.com> Thu, 09 July 2015 02:23 UTC

Return-Path: <wdenniss@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8001D1A010E for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2015 19:23:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqbXHF27XpoF for <oauth@ietfa.amsl.com>; Wed, 8 Jul 2015 19:23:46 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EDB1A89EB for <oauth@ietf.org>; Wed, 8 Jul 2015 19:22:43 -0700 (PDT)
Received: by qkhu186 with SMTP id u186so177398356qkh.0 for <oauth@ietf.org>; Wed, 08 Jul 2015 19:22:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zUCXfIP/IL95o84FIyqjwbGilExCwsR5blQckwjVYGI=; b=O1q3kh9DdeirOVewN27wuLxkslS+PNZnrglOMai20wxG0jf3AdBTwfBVo0DixqjqZ2 ZpJJ7P9gXWniryi5qsbjsFS/qSsLPfkseVmPgubZ8nH9QRquC25RBxniU3M3Ltt6M1RU JtBiUlU5H18hE9xhpBgpbMyZ61E9SnwdeZfG7cB6zlqQgjv+HNO2jMi0yGwtLZoa4QFh bK21tNwI9YOFAWm7lDveVGq4bmvnJqqNieotdVI1SUpQrXTzHIQRISYkEFFwmu7HZxUp /b1vbwdRiNbDKLsztncrdA5FhXLuqSWIiqX3KaCPDctusFL0XUvvS6NMG1GUAOBF4w/c ABZg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=zUCXfIP/IL95o84FIyqjwbGilExCwsR5blQckwjVYGI=; b=ASEdnpIkfX0IWvtUrkrV8mAw00WZ+RtDqK8GhLkz8tlWHhrMX8X/G2eZqgaH5/xl4I 6Rx/BQeEG9rPSqeYIP/SQIDMG654q4hhjwLy+8AF23eqy+YCfd/YZJOL59MlRGtTIImC acf+wuGXcr3mADE1U3zB0YR5TEwCXP/bEzwsWN03apz0wKuLpXNGTgk68pBKVBBFvN8/ kGBWi74qQrWQmNAKsruEonqBftIYENmNhmCPnvyD+FYKxMgcNZmJ8Ev2IeEvt7CxgvGr MNmGnG65fNwBhqa5bl0pfckKGvyuhgMYjMDHmm5uuRwD5ha2U4uhQVFR+2cPbrKG3aaZ 8pYA==
X-Gm-Message-State: ALoCoQmCleTntzU5OdFsfzzsTXZ0Zq7HvxvPh2Z0SCNYdw0JpqC60HQf+4FMqPExQXpE9twwF4gU
X-Received: by 10.140.100.146 with SMTP id s18mr10712580qge.36.1436408562348; Wed, 08 Jul 2015 19:22:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.19.98 with HTTP; Wed, 8 Jul 2015 19:22:22 -0700 (PDT)
In-Reply-To: <CAAP42hDMH9gc97aa3-hjrLuRyFsc3j8tmSwDee-oJvMn4dxsAg@mail.gmail.com>
References: <20150706230550.12450.15077.idtracker@ietfa.amsl.com> <CAAP42hD=CXnWUgQ5b=cgtqp2TkOgXWQ89yZtyEJe9_19K+72Mw@mail.gmail.com> <68C4B3E0-0A40-4035-A6B8-EB553573BE5D@ve7jtb.com> <CAAP42hDMH9gc97aa3-hjrLuRyFsc3j8tmSwDee-oJvMn4dxsAg@mail.gmail.com>
From: William Denniss <wdenniss@google.com>
Date: Wed, 8 Jul 2015 19:22:22 -0700
Message-ID: <CAAP42hA9B4HNURC6wZ+KBLre-VCXSz_BROZ6qcjSQ0ZTX4YC-w@mail.gmail.com>
To: John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary=001a1134e3941cada0051a67ee50
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/9NdLGKv09z796rRRAcX9DqI2k3g>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-spop-14.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 09 Jul 2015 02:23:48 -0000

Following up the discussion on today's NAPPS call, I understand why plain
is not presented as the recommended approach in the spec (though it still
has some value over not doing PKCE at all, in that it mitigates against the
current known attack where a rogue app registers the same custom URI scheme
as another), but I feel that after all the back and forth the picture is a
little confusing.

In particular, 4.2 and 4.4.1 include some examples where plain is supported:

4.2
> Clients SHOULD use the S256 transformation.  The plain transformation is
> for compatibility with existing deployments and for constrained
> environments that can't use the S256 transformation.
>


4.4.1.
> If the client is capable of using "S256", it MUST use "S256", as "S256" is
> Mandatory To Implement (MTI) on the server. Clients are permitted to use
> "plain" only if they cannot support "S256" for some technical reason and
> knows that the server supports "plain".


But then 7.2 is very vocal that it MUST NOT be used for new implementations:

7.2
> Because of this, "plain" SHOULD NOT be used, and exists only
> for compatibility with deployed implementations where the request path
> is already protected.  The "plain" method MUST NOT be used in
> new implementations.


 What if those new implementations are constrained, as indicated in 4.2 and
4.4.1?


Also, while S256 is clearly indicated as MTI, little is said about "plain",
although it's alluded to that it's not MTI in 4.4.1 ("and knows that the
server supports "plain"").

Should we be more explicit upfront that "plain" is optional for servers to
support, if that's the intention?


On Tue, Jul 7, 2015 at 10:51 PM, William Denniss <wdenniss@google.com>
wrote:

> t_m works for me, I just think we should have some indication that it's
> the name of the transform. Will you also update where it is referenced in
> the description below Figure 2?
>
>
>
> On Tue, Jul 7, 2015 at 6:28 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> Thanks, I fixed my finger dyslexia for the next draft.
>>
>> I changed it to t_m rather than “t”  I think that is clearer.  If I were
>> to do it the other way XML2RFC would have double quotes in the text version.
>>
>> John B.
>>
>> On Jul 7, 2015, at 9:38 PM, William Denniss <wdenniss@google.com> wrote:
>>
>> In version 14, there's a typo on this line ("deso") in Section 7.2:
>>
>> `"plain" method deso not protect`
>>
>> Also, in the 1.1 Protocol Flow diagram, regarding the text:
>>
>> `+ t(code_verifier), t`
>>
>> I wonder if it makes more sense to represent as `+ t(code_verifier), "t"`
>> (note the quotes on the second 't') given that it's a string representation
>> of the method that's being sent?
>>
>>
>> On Mon, Jul 6, 2015 at 4:05 PM, <internet-drafts@ietf.org> wrote:
>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>>  This draft is a work item of the Web Authorization Protocol Working
>>> Group of the IETF.
>>>
>>>         Title           : Proof Key for Code Exchange by OAuth Public
>>> Clients
>>>         Authors         : Nat Sakimura
>>>                           John Bradley
>>>                           Naveen Agarwal
>>>         Filename        : draft-ietf-oauth-spop-14.txt
>>>         Pages           : 20
>>>         Date            : 2015-07-06
>>>
>>> Abstract:
>>>    OAuth 2.0 public clients utilizing the Authorization Code Grant are
>>>    susceptible to the authorization code interception attack.  This
>>>    specification describes the attack as well as a technique to mitigate
>>>    against the threat through the use of Proof Key for Code Exchange
>>>    (PKCE, pronounced "pixy").
>>>
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>>>
>>> There's also a htmlized version available at:
>>> https://tools.ietf.org/html/draft-ietf-oauth-spop-14
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-spop-14
>>>
>>>
>>> Please note that it may take a couple of minutes from the time of
>>> submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>