Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwsreq-12: (with COMMENT)

Nat Sakimura <sakimura@gmail.com> Sat, 18 February 2017 20:23 UTC

Return-Path: <sakimura@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 C90D11295C8; Sat, 18 Feb 2017 12:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hbg2du4_Cyot; Sat, 18 Feb 2017 12:23:30 -0800 (PST)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 6D698129572; Sat, 18 Feb 2017 12:23:30 -0800 (PST)
Received: by mail-wm0-x236.google.com with SMTP id 196so15488133wmm.1; Sat, 18 Feb 2017 12:23:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SnzHu9LMalNHXwJY+2gT1Ugz5dfe064Yj5JL1vLLh4E=; b=k0PwSMWMLkY8B4Ung2PDnB1Dn+8HF6xUKutV9SHsXD9NOmqLX/2BB2HU2sBwmbg8gh NOz382N7TpVJjVdWWnhIV/p288TUC4HMhBHm7TEf5Kw+hXISLfHvyL8xWw7Xg70bODkT LBIhKUtGyoAabSvrLbMR2QHtDTt5xryuVQhSWAKPLsZhhbl5yFxENiwVYchPj11qaraG bfp09G5E3EZWiMZFbsTgfc8yjDKhf/KuYe7y9tB5v3xBxG/8nCgOMK8hB/HJio0HvJ8O ClZOSyZ7TJIoptc4Klhn6L9mVpbXCapezaeWnK1jeyMBkcLTncEquq3jR/ufkGQOL+n+ Yr8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SnzHu9LMalNHXwJY+2gT1Ugz5dfe064Yj5JL1vLLh4E=; b=dl0qxf4KbB/EjUoJy+w7IsjNdysdQ/gFEZWi/+gybO40ojd66SymDP2uvCGlmNSwA9 MV+Ca5eZFKtxK0XDvgGC48v61o2ycUL/kcEcRYcEHGqsruO09kO+DdpGzHsasToYC89w NaXx7W6Dk0gqIVkMrthTXSBKtOg+ighYf/bBmXo+dl3iLWZVtVq9MYwzM9l33de3noWB /LqI80/vLO1DTOqRPCqbE/3HTCfx0KWlIByVVByv8WxsLv481ou87tg+6EXF7I5CFxY9 HXgyRGBOGF1AQjj7ZEIg51DcoK3ldrRpY3zGu1U9gXczmhU6gL2fmT3Egj3SPFMuwh8f z7Pw==
X-Gm-Message-State: AMke39kUada1qdzLALcPVAZV+EawCl3Pg3lWF7p3ofPn8LjmnLn9raXRaPLEre17qbTdlR/aAqyps6sdV9duJA==
X-Received: by 10.28.15.2 with SMTP id 2mr11050576wmp.66.1487449408917; Sat, 18 Feb 2017 12:23:28 -0800 (PST)
MIME-Version: 1.0
References: <148720444007.31614.4351735589682369445.idtracker@ietfa.amsl.com>
In-Reply-To: <148720444007.31614.4351735589682369445.idtracker@ietfa.amsl.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Sat, 18 Feb 2017 20:23:18 +0000
Message-ID: <CABzCy2COaN9pLP-TKPWTjcSU6dcqci=AyQUDi-QeHJe8r4OFgg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: multipart/alternative; boundary=001a1146995ea3de370548d3cd90
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/aGW1Gc-6UAwlVqwD0IeeajpXjFU>
Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org, oauth-chairs@ietf.org
Subject: Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-jwsreq-12: (with COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 18 Feb 2017 20:23:33 -0000

Hi Stephen,

Thank you very much for your thoughtful comments.
My response (after discussing with John) inline:

On Thu, Feb 16, 2017 at 9:20 AM Stephen Farrell <stephen.farrell@cs.tcd.ie>;
wrote:

> Stephen Farrell has entered the following ballot position for
> draft-ietf-oauth-jwsreq-12: 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-jwsreq/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> - intro: "attacks... have been identified." yells out for a
> reference - it'd be a good bit better if implementers could
> easily find details of some such attacks, so I hope you add
> some refs here.
>

Will do.


>
> - section 3; WAP? Really? I'm surprised any WAP technology
> would still be in use, even on feature-phones. Do you really
> need this?
>

WAP/cHTML and the variation there of. It may not be truly WAP but it would
exemplify those. I could have said "limited capaibility browsers" but then
that would sound like something akin of mobile browsers on smartphones.


>
> - section 4: I think it will turn out to be an error to allow
> for mixing query parameters and protected parameters (in a
> Request Object) in a single request. Do you really need that
> level of flexibility? It'd be simpler and less likely to be
> attackable to insist that all parameters be in the Request
> Object if one is used. (See also section 11.2.1 below.)
>
> Right.
The benefit of the flexibility is not big and may not warrant the cost
associated with it.


> - section 10: Is there nothing to be said about the new
> indirection caused by the request_uri? I'd have thought there
> were some corner cases that'd warrant a mention, e.g. if some
> kind of deadlock or looping could happen, or if one client (in
> OAuth terms) could use a request_uri value as a way to attempt
> attacks (to be assisted by an innocent browser) against some
> resource owner.
>

Good point. I can think of several attack surfaces such as DoS attack to
the authorization server. I could not come up with an attack against the
resource owner for the time being though.


>
> - section 11: thanks for that, it's good.
>
> - section 11: Saying that an ISO thing is "good to follow" is
> quite weak IMO. (And is that ISO spec accessible? Hmm...  it
> seems that one needs to accept cookies to get it which is
> wonderfully ironic;-) If the authors have the energy, I'd
> suggest trying to find better guidance that's more publically
> available in a privacy-friendly manner. (Or just drop the ISO
> reference if 6973 is good enough.)
>
>
When I first put in the reference to 29100, I meant to write a fuller write
up using it as it would be useful for the orgaanizations implementing ISMS.
(Privacy extensions to ISMS are written based on 29100).
But I did not. I may just drop the reference as well since collection
minimization and disclosure minimization probably is self evident.

Best,

Nat

>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
-- 

Nat Sakimura

Chairman of the Board, OpenID Foundation