Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Tue, 07 July 2015 20:40 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 562031A8F34; Tue, 7 Jul 2015 13:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 07VIGchw4Ml5; Tue, 7 Jul 2015 13:40:52 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::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 00B341A6FF2; Tue, 7 Jul 2015 13:40:51 -0700 (PDT)
Received: by wgck11 with SMTP id k11so178348434wgc.0; Tue, 07 Jul 2015 13:40:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=x5b8/dB4xnOYQm2w7TD345cjC7dEqu4EqC8zGXjrGxE=; b=BaEmfSxP8W/dJ5Z0Loc+MYvCxSvmWfnpKu+yWLFnShaqvFMS/zHP/S5Yo8BspXR7/i 5tkPT2Fw5Mx+MIQLU8oEM0Or9R8Wc3u9hsm96Z9fltpC6egNFK1By8dHsZgnZuqh0Re9 erm183zY5QSfqkPURw6ceDeAw50xBajB3DNdfF3Iycmaho3mV10Z74MbbiOsoHN0d5DV 3yaZ3ur4ocA8fcLbfuRV+W0w5NQ1Z2n1u7jHgWmtWekKdG1nqLuvR2/WFuR6APQyjYWP KbFXgMWkI1QNTJT3oIwuliW9j2+SVZ0M5hWRvQq0rV9yAIe0Xv80Rp7Hvt3cahEz5oCx qLVQ==
MIME-Version: 1.0
X-Received: by 10.194.91.193 with SMTP id cg1mr12313972wjb.86.1436301650766; Tue, 07 Jul 2015 13:40:50 -0700 (PDT)
Received: by 10.28.31.194 with HTTP; Tue, 7 Jul 2015 13:40:50 -0700 (PDT)
In-Reply-To: <CA+k3eCQDZcQmzvwv7VaTTktEoUbBmqaurH=QvSkByDVvihSUeQ@mail.gmail.com>
References: <20150707024902.24716.2952.idtracker@ietfa.amsl.com> <CABzCy2AW474zv7EU0EZ3UpQP74S2CRmBZuzLs8FG_=Ey7E_GXw@mail.gmail.com> <CA+k3eCQDZcQmzvwv7VaTTktEoUbBmqaurH=QvSkByDVvihSUeQ@mail.gmail.com>
Date: Tue, 7 Jul 2015 16:40:50 -0400
Message-ID: <CAHbuEH7mH490wDam+LEgHUj85PqOk0H5KRsFLxztoxQi5O01Mw@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary=047d7bd907bcaf2ee0051a4f0913
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/v5ZmwSFWl0wpY5FkfPHPzbNahhc>
Cc: draft-ietf-oauth-spop@ietf.org, oauth <oauth@ietf.org>, draft-ietf-oauth-spop.shepherd@ietf.org, The IESG <iesg@ietf.org>, Barry Leiba <barryleiba@computer.org>, oauth-chairs@ietf.org, draft-ietf-oauth-spop.ad@ietf.org
Subject: Re: [OAUTH-WG] Barry Leiba's No Objection on draft-ietf-oauth-spop-14: (with COMMENT)
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: Tue, 07 Jul 2015 20:40:55 -0000

Thanks for your responses on these comments.

I can approve an updated draft to make this change and the one for IANA if
that is the easiest path.  The other option is to write this all up in an
RFC editor note and I can send that with the approval.  Making the direct
updates may be simpler to avoid mistakes.

Can you submit a new version?

Thank you,
Kathleen

On Tue, Jul 7, 2015 at 12:35 PM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

> Regarding the comment on Section 2, I had originally argued for the
> inclusion of ASCII(xxx) as I felt it was important to avoid potential
> ambiguity that was in the draft at the time (it wasn't 100% clear to me at
> the time if the code_verifier was to be base64url decoded as input into the
> hash or if the ASCII bytes were to be used). However, other content
> (particularly §4.1
> <https://tools.ietf.org/html/draft-ietf-oauth-spop-14#section-4.1>) has
> since changed and removed the potential for the ambiguity I thought might
> be there.
>
> Which is a long way of explaining that I'm okay with Barry's proposed
> change to Section 2, and occurrences of ASCII(...) throughout, despite it
> undoing something I'd previously requested.
>
> On Tue, Jul 7, 2015 at 10:09 AM, Nat Sakimura <sakimura@gmail.com> wrote:
>
>> Thanks Barry,
>>
>>
>> These are the issues that I wanted to discuss with John before making
>> change.
>>
>> -- Section 6.2 -- John has partly addressed your IANA comment already. I
>> needed
>> to check if there was any reason for just doing partly.
>>
>> -- Section 7.2 -- is probably just my oversight. I will deal with it.
>>
>> -- Section 2 -- : I agree with you and I wanted to confirm it with John
>> and other people to commit the change.
>>
>> Cheers,
>>
>> Nat
>>
>> 2015-07-07 11:49 GMT+09:00 Barry Leiba <barryleiba@computer.org>rg>:
>>
>>> Barry Leiba has entered the following ballot position for
>>> draft-ietf-oauth-spop-14: No Objection
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>> Please refer to
>>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>>> for more information about IESG DISCUSS and COMMENT positions.
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> Version -14 resolves my DISCUSS (and also some of my non-blocking
>>> comments).  Thanks very much for considering these and working with me on
>>> them!
>>>
>>>   =========================================
>>> My comment about the IANA Considerations remains.  While it's
>>> non-blocking, I still hope you will accept the change I suggest:
>>>
>>> -- Section 6.2 --
>>> I have the same comment here as in the other OAuth document: please shift
>>> the focus away from telling IANA how to handle tracking of the expert
>>> review, and make the mailing list something that the designated expert(s)
>>> keep track of.  Also, please give more instructions to the DEs about what
>>> they should consider when they're evaluating a request (for example,
>>> should they approve all requests, or are there criteria they should
>>> apply?).
>>>
>>> For the first, here's a text change that I suggest we move toward for
>>> this sort of thing:
>>>
>>> OLD
>>> <most of Section 6.2>
>>>
>>> NEW
>>>    Additional code_challenge_method types for use with the authorization
>>>    endpoint are registered using the Specification Required policy
>>>    [RFC5226], which includes review of the request by one or more
>>>    Designated Experts.  The DEs will ensure there is at least a two-week
>>>    review of the request on the oauth-ext-review@ietf.org mailing list,
>>>    and that any discussion on that list converges before they respond to
>>>    the request.  To allow for the allocation of values prior to
>>>    publication, the Designated Expert(s) may approve registration once
>>>    they are satisfied that an acceptable specification will be
>>> published.
>>>
>>>    Discussion on the oauth-ext-review@ietf.org mailing list should use
>>>    an appropriate subject, such as "Request for PKCE
>>>    code_challenge_method: example").
>>>
>>>    The Designated Expert(s) should consider the discussion on the
>>>    mailing list, as well as <<these other things>> when evaluating
>>>    registration requests.  Denials should include an explanation
>>>    and, if applicable, suggestions as to how to make the request
>>>    successful.
>>> END
>>>
>>>   =========================================
>>> -- Section 7.2 --
>>> I find the first first paragraph confusingly worded, and after discussion
>>> with the author I suggest this:
>>>
>>> NEW
>>> Clients MUST NOT downgrade to "plain" after trying the S256 method.
>>> Because servers are required to support S256, an error when S256 is
>>> presented can only mean that the server does not support PKCE at all.
>>> Otherwise, such an error could be indicative of a MITM attacker trying
>>> a downgrade attack.
>>> END
>>>
>>>   =========================================
>>> Finally, there is this comment, which is not a big deal and you should
>>> proceed as you think best:
>>>
>>> -- Section 2 --
>>> There is no real distinction between STRING and ASCII(STRING), because
>>> STRING is already defined to be ASCII.  Using "ASCII(xxx)" only adds
>>> clutter, and a suggest removing it.
>>>
>>> So, for example, that would result in changes such as this:
>>>
>>> OLD
>>> BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) == code_challenge
>>> NEW
>>> BASE64URL-ENCODE(SHA256(code_verifier)) == code_challenge
>>> END
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>


-- 

Best regards,
Kathleen