Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt

Justin Richer <jricher@mit.edu> Fri, 22 November 2019 07:24 UTC

Return-Path: <jricher@mit.edu>
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 CB5E5120033 for <oauth@ietfa.amsl.com>; Thu, 21 Nov 2019 23:24:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 NE5iIjJ3PAj7 for <oauth@ietfa.amsl.com>; Thu, 21 Nov 2019 23:24:50 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2B812008A for <oauth@ietf.org>; Thu, 21 Nov 2019 23:24:49 -0800 (PST)
Received: from dhcp-9862.meeting.ietf.org (dhcp-9862.meeting.ietf.org [31.133.152.98]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAM7OgNo020786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Nov 2019 02:24:46 -0500
From: Justin Richer <jricher@mit.edu>
Message-Id: <6DECA422-AACC-4DAA-8CD2-FF57CE02DE3E@mit.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A139A001-C7CB-47B1-8D4C-B3F2F17CFA6D"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 22 Nov 2019 15:24:41 +0800
In-Reply-To: <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com>
Cc: Neil Madden <neil.madden@forgerock.com>, oauth <oauth@ietf.org>
To: Dick Hardt <dick.hardt@gmail.com>
References: <2EF412B8-AF8C-4642-9BE0-1B528B0C63D5@amazon.com> <288343F2-ACF0-43E0-8577-26AF45330E5C@forgerock.com> <CAD9ie-u_SM+1hRuBWR7zBGSi4Ex59Ht0SzoVTeFuWTRc3cFJXw@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/IETUKInc85FTdNIy9qKJn6Wgb8I>
Subject: Re: [OAUTH-WG] New Version Notification for draft-fett-oauth-dpop-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 22 Nov 2019 07:24:52 -0000

I’m going to +1 Dick and Annabelle’s question about the scope here. That was the one major thing that struck me during the DPoP discussions in Singapore yesterday: we don’t seem to agree on what DPoP is for. Some (including the authors, it seems) see it as a quick point-solution to a specific use case. Others see it as a general PoP mechanism. 

If it’s the former, then it should be explicitly tied to one specific set of things. If it’s the latter, then it needs to be expanded. 

I’ll repeat what I said at the mic line: My take is that we should explicitly narrow down DPoP so that it does exactly one thing and solves one narrow use case. And for a general solution? Let’s move that discussion into the next major revision of the protocol where we’ll have a bit more running room to figure things out.

 — Justin

> On Nov 22, 2019, at 3:13 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
> 
> 
> 
> On Fri, Nov 22, 2019 at 3:08 PM Neil Madden <neil.madden@forgerock.com <mailto:neil.madden@forgerock.com>> wrote:
> On 22 Nov 2019, at 01:42, Richard Backman, Annabelle <richanna@amazon.com <mailto:richanna@amazon.com>> wrote:
>> There are key distribution challenges with that if you are doing validation at the RS, but validation at the RS using either approach means you’ve lost protection against replay by the RS. This brings us back to a core question: what threats are in scope for DPoP, and in what contexts?
> 
> 
> Agreed, but validation at the RS is premature optimisation in many cases. And if you do need protection against that the client can even append a confirmation key as a caveat and retrospectively upgrade a bearer token to a pop token. They can even do transfer of ownership by creating copies of the original token bound to other certificates/public keys. 
> 
> While validation at the RS may be an optimization in many cases, it is still a requirement for deployments.
> 
> I echo Annabelle's last question: what threats are in scope (and out of scope) for DPoP?
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth