Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and COMMENT)

Justin Richer <jricher@mit.edu> Fri, 24 April 2015 12:28 UTC

Return-Path: <jricher@mit.edu>
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 4D8C61B2C27; Fri, 24 Apr 2015 05:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zfEuFAOjDiKv; Fri, 24 Apr 2015 05:28:30 -0700 (PDT)
Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC9F1ACE15; Fri, 24 Apr 2015 05:28:29 -0700 (PDT)
X-AuditID: 1209190c-f792b6d000000d1f-1d-553a36ecd36d
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2F.84.03359.CE63A355; Fri, 24 Apr 2015 08:28:28 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t3OCSRXN013175; Fri, 24 Apr 2015 08:28:27 -0400
Received: from [192.168.128.56] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3OCSPDY012514 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2015 08:28:26 -0400
Message-ID: <553A36DE.5040501@mit.edu>
Date: Fri, 24 Apr 2015 08:28:14 -0400
From: Justin Richer <jricher@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: oauth@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>, oauth-chairs@ietf.org, draft-ietf-oauth-dyn-reg@ietf.org
References: <20150424115205.3265.73381.idtracker@ietfa.amsl.com>
In-Reply-To: <20150424115205.3265.73381.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixG6novvGzCrUoL9X02Laz9dsFjP+TGS2 uD13JZvFybev2Cym773G7sDqsbb7KpvHkiU/mQKYorhsUlJzMstSi/TtErgyOvbcZSloU6jY tHgnewPjNckuRk4OCQETie37XrJA2GISF+6tZ+ti5OIQEljMJPG+4TsjhLORUWL1rlNQzm0m iSlPf4O18AqoSbx8+54ZxGYRUJXYtuw8K4jNBmRPX9PCBGKLCkRJTPx6CKpeUOLkzCcsIINE BJYySiw8vg+sQVggT6LjUBcbiC0k4CDx5O4PoGYODk4BR4mPU8pAwswCthJ35u5mhrDlJba/ ncM8gVFgFpKxs5CUzUJStoCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuoV5uZoleakrpJkZQ IHNK8uxgfHNQ6RCjAAejEg/vjDmWoUKsiWXFlbmHGCU5mJREeTulrEKF+JLyUyozEosz4otK c1KLDzFKcDArifA+MwDK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ 8P4xAWoULEpNT61Iy8wpQUgzcXCCDOcBGl5uCjK8uCAxtzgzHSJ/ilFRSpzXDiQhAJLIKM2D 64UlmleM4kCvCPMuA6niASYpuO5XQIOZgAbPXGoBMrgkESEl1cDYb14ueP1dgcS3v03b+q6f PrDxn/zucy9XiJ/xWH3/7e8MJU5f2SvHHveVtuxaPkHtX9kqvc55AjaxdzO5jCau8JTZ1cBe 6nOge/fNmQIlc1TcTA48m6u64XpmT0Lr2k36dfLr+5f0NEeWNhsvX/EwlGl60LOGR/5LS30X GH1QOME6/x3X7G4/JZbijERDLeai4kQATlco7Q8DAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/0ZYzWmjqcJLbRAcWf6su_iiiUD0>
Subject: Re: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-dyn-reg-28: (with DISCUSS and 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: <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, 24 Apr 2015 12:28:32 -0000

> I do wonder
> though if you ought also say a bit about, or point at a
> reference describing, the possible bad outcomes if
> one of these URLs  goes bad. The new text I think
> assumes that the developer will get how bad that can
> be, but I'm not sure if they would or not.

It can get as bad as the web, which is pretty bad, but I hope we don't 
have to point that out in great detail in every RFC that deals with the 
web. :) I think the drive-by-download malware example is a good one, and 
we could add another concrete one if you've got an idea, but I think the 
advice we have is sound and actionable and we should avoid having this 
spec be a catalogue of "bad things what can happen on the web". If there 
is such a reference, I'm happy to point to it!

  -- Justin

On 4/24/2015 7:52 AM, Stephen Farrell wrote:
> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-dyn-reg-28: Discuss
>
> 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 http://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:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-dyn-reg/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> (1) cleared
>
> (2) If the response (defined in 3.2.1) includes metadata that
> the server has altered, but that the client doesn't like, then
> what does the client do? (It may be that that's ok, but I'm
> not following why that is the case.) I'm also not sure the
> "https" requirement (1st bullet in section 5) is useful there.
>
> We had some mail discussion on this but I'd like to
> continue that a bit more to understand if the changes
> in -28 address the issue. I'll send mail.
>
> (3) cleared
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> My previous DISCUSS point (1) is below. That has been
> handled via new text in section 5 (on p27). I do wonder
> though if you ought also say a bit about, or point at a
> reference describing, the possible bad outcomes if
> one of these URLs  goes bad. The new text I think
> assumes that the developer will get how bad that can
> be, but I'm not sure if they would or not.
>
> (1) General: there are many URIs sent to the AS from the
> client here. Nothing prevents the client messing about with
> the content served from those later, after registration. What
> mechanism holds clients accountable for such misbehaviours?
> (Examples, logo_uri, tos_uri, policy_uri, jwks_uri) Section 5
> does say that the AS "SHOULD check" but does not say what
> "checking" means, nor what to do if the check fails.  I think
> a bit more security considerations-like text here, reflecting
> what is (or ought;-) actually be done would be good. Do you
> agree?
>
>
> --- OLD COMMENTS, I didn't check if they'd been handled
>
> - s2, software_version: what is the impact if the s/w is
> updated twice a day, every day?
>
> - 3.2.1 - why is the response status 201? That may be correct,
> but seems to subtle if so to only state in an exmaple.
>
> - s5, last para - "be very particular" is not good spec
> language - what do you actually mean that can be implemented?
>
> - thanks for section 6 - it's great to see thought being
> devoted to these issues.
>
> - Did the secdir review [1] get a response? And I think I
> quite agree with Charlie's point#2 about versions.
>
>     [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05519.html
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth