Re: [Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07

Phil Hunt <phil.hunt@yahoo.com> Thu, 17 December 2015 07:41 UTC

Return-Path: <phil.hunt@yahoo.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F6E1B2AA4 for <gen-art@ietfa.amsl.com>; Wed, 16 Dec 2015 23:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=unavailable
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 B5sMlNRZcrVJ for <gen-art@ietfa.amsl.com>; Wed, 16 Dec 2015 23:41:06 -0800 (PST)
Received: from nm28-vm1.bullet.mail.ne1.yahoo.com (nm28-vm1.bullet.mail.ne1.yahoo.com [98.138.91.35]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD7E1B2A9A for <gen-art@ietf.org>; Wed, 16 Dec 2015 23:41:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1450338065; bh=Rcrq9MZiOLcuLnaa0uwltMa0DuoUIfeyRCI93lKPavQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=Fmm/pcEIkW04NtL+G627Yo/C2NwZG8/bcUlHf160r++HwOVFwFOSeiZMfEi+5HzZ+WtWe+hF1kZdbsv0UE5k95in3dK4zwdxLzOAav5mkwZalj8h2hjwbKEbB+5UZeAvl72OrF+2QdpeMBT+X7RWC0OIHRj/rVWpgIZOouYF6Itpv8WStxDAc7youWs9ztssn87eePMjHOawoQgJxK/dhvpi/pZGhE7xPWp5+ZCrclLMvjE0Mz5/v9cQrqz8nn5Y7FOpmsSblZhgGz4Ldo3kdK12gUBtoIJ9lCLJKjb543UWGUw11KU0LGFrMiCK5vMD8o+Twz36K67C27E34ylqXw==
Received: from [98.138.226.178] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 17 Dec 2015 07:41:05 -0000
Received: from [98.138.84.41] by tm13.bullet.mail.ne1.yahoo.com with NNFMP; 17 Dec 2015 07:41:05 -0000
Received: from [127.0.0.1] by smtp109.mail.ne1.yahoo.com with NNFMP; 17 Dec 2015 07:41:05 -0000
X-Yahoo-Newman-Id: 909967.75290.bm@smtp109.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: ENV4mRkVM1lxWJ.1vgCwA9g6DVZzyhVmxmsaL5rQzhhnBGB 5Y2_NXMnE8fbgmkT1f2nRprbi8RyyRFqvS26nlBgZMVsmg72g0SAOyf9ezuC tQHuv4cpsl0Z2cTwuIZnjHDhiDJOlArB8Hq7CA0PPiZ17.mlcYNkOfQgIK0v LMz45q5xb62lXEEdDFitZHUHIq9x7OyCkTW3KKPDrozYly2jlzNA1BkjZSTa KHs3LONgeuH0cRYWfuSQWsc0MZcEhPTMW0JDkShrmBRpTOSX7MaeDWQujRpW VEs_RTKrhpPjWkdClmVonu_DqNVq8s1Xj4.R8QFcxrTREwKP51wh8RHpfc_o sxiemwVLUqOoDmPxr3aUcgjvSK4pytCZt6kksvw7G77unWpqYfpuMUQJLk6U 5AqpXR64Tvhp3jImn9HOnblKGBX3LlBEIvQ69F34xEPArrBO6MEZrWWwvgwb qB_rZQMUQiy7aQcOUj193dhlgLaCh8JGK3wpdVxclFNNmFNwq5EeTOT7G9YS kJjhyKNyB2B3g7DEHyWSEpYVp_GRyMWf.
X-Yahoo-SMTP: 5ZG1WouswBA_I3TiUVQ.pojpE5jY8w--
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Phil Hunt <phil.hunt@yahoo.com>
X-Mailer: iPhone Mail (13C75)
In-Reply-To: <CAHbuEH6TXnXdiFsyCStAZmOFwEEvoBWbf_DdSX7a3m=CW1FJag@mail.gmail.com>
Date: Thu, 17 Dec 2015 08:40:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <7B128318-4EBC-49FE-BECE-57A2061AF6EB@yahoo.com>
References: <2A457E0F-1ADC-4C4A-B6C8-3B29DEF46BAF@cisco.com> <CAHbuEH6TXnXdiFsyCStAZmOFwEEvoBWbf_DdSX7a3m=CW1FJag@mail.gmail.com>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/67kca05lYCU1BV6LgvPZh-dxczs>
Cc: "draft-ietf-oauth-pop-architecture.all@ietf.org" <draft-ietf-oauth-pop-architecture.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Subject: Re: [Gen-art] Telechat review of draft-ietf-oauth-pop-architecture-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Dec 2015 07:41:08 -0000

Matt

Thanks for the great review. As Kathleen mentioned, there are some other changes we have to make that will push the draft back. Never-the-less I will take into account all the reviewer comments in the next draft. 

All your comments seem very reasonable to me. 

Thanks,

Phil

> On Dec 17, 2015, at 04:02, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
> 
> Hi Matt,
> 
> Thank you for your review!  The editors will take these comments into
> consideration and discuss any updates.  I'll note that the draft was
> pulled from the telechat and will likely not go through last call
> again until sometime around Buenos Aires due to some other changes
> that came up.  You may see this one again.
> 
> Thanks,
> Kathleen
> 
> On Wed, Dec 16, 2015 at 9:28 PM, Matt Miller (mamille2)
> <mamille2@cisco.com> wrote:
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>> 
>> For more information, please see the FAQ at
>> 
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>> 
>> Document: draft-ietf-oauth-pop-architecture-07
>> Reviewer: Matthew A. Miller
>> Review Date: 2015-12-16
>> IETF LC End Date: 2015-12-15
>> IESG Telechat date: 2015-12-17
>> 
>> Summary: Almost ready.
>> 
>> I have several editorial nits, but also a couple of minor concerns that
>> I think would improve this document's readability.
>> 
>> I note that idnits complained about the lack of RFC 2119 boilerplate;
>> however, I think the text actually used in this document is most
>> appropriate and still conveys the intent.  The idnits also complained
>> about a reference to an obsolete RFC 5849; however, this reference
>> appears to be intentional and necessary.
>> 
>> -----
>> 
>> Major issues:
>> 
>> Nnne.
>> 
>> Minor issues:
>> 
>> 1. In Section 1. Introduction, the last paragraph makes it seem the
>> document isn't organized properly.  It implies an order to read the
>> document that is not reflected in the outline:
>> 
>> * Section 1
>> * Section 2
>> * Section 3
>> * Section 4
>> * Section 6
>> * Section 7
>> * Section 5
>> 
>> Simply re-ording the document I think causes bigger problems.  While
>> the intro hints at the order to read, it makes more sense to me in
>> the order it actually is.  Ultimately, for me the problem arises with
>> the word "concludes".  It might simply be enough to change the last
>> participle from ", and concludes with a requirements list in Section 5."
>> to ", and lists requirements in Section 5."
>> 
>> 2. In several places, terms of art are used that have not been defined
>> in this document: "resource server", "protected resource", etc.  I
>> think it would help if Section 2. indicated where these terms are
>> defined or discussed, which is RFC 6749.
>> 
>> 
>> Nits/editorial comments:
>> 
>> * The reference to draft-ietf-oauth-proof-of-possession-08 should be
>> updated to its latest version, although I expect RFC Editor will
>> resolve this before publication.
>> 
>> * The reference to RFC 4347 should be updated to 6347; there's no clear
>> requirement for the older document.
>> 
>> * In Section 3.1 Preventing Access Token Re-Use by the Resource Server,
>> "with other resource server" should be either "with another resource
>> server" or "with other resource servers".
>> 
>> * In Section 3.2 TLS and DTLS Channel Binding Support, "entity entity"
>> should be "entity".
>> 
>> * In section 3.4 Offering Application Layer End-to-End Security, The
>> last sentence of the last paragraph seems out of place.  It seems it
>> would be better as the penultimate sentence of the previous paragraph.
>> 
>> * In section 4. Security and Privacy Threats under "Token
>> manufacture/modification", "causing resource server" should be "causing
>> the resource server".
>> 
>> * Also in Section 4. Security and Privacy Threats under "Token
>> manufacture/modification", the normative language here seems out of
>> place.  It seems to me that 'may' conveys just as much as 'MAY' for
>> how it is used here.
>> 
>> * In Section 5. Requirements under "Prevent the Domino Effect",
>> "Resource Server" is capitalized differently than all previous uses,
>> but it doesn't seem to be a different use.  I suggest changing it to
>> "resource server".
>> 
>> * In Section 6.3. Key Confirmation, uses the term "privacy key" where
>> I believe the common nomenclature is "private key".
>> 
>> * In Section 7. Client and Authorization Server Interaction, I find
>> most of the figures a little hard to follow.  While I appreciate the
>> attempt to go beyond strict perpendicularity, I find it distracting
>> from the information it is trying to convey.
>> 
>> * In Section 7.1 Symmetric Keys, I think the "three ways for
>> communicating this session key" would benefit having bullets or
>> outline numbers.
>> 
>> * In Section 10. Acknowledgements, the second paragraph discusses an
>> appendix that borrows content from another document, but there is no
>> appendix in this draft.  Is this text still relevant?
>> 
>> 
>> --
>> - m&m
>> 
>> Matt Miller
>> Cisco Systems, Inc.
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen