IETF Logo Mail Archive

Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments

Benjamin Kaduk <kaduk@mit.edu> Wed, 08 April 2020 04:51 UTC

Return-Path: <kaduk@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 718613A0C20 for <oauth@ietfa.amsl.com>; Tue, 7 Apr 2020 21:51:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 3TfYXWzmTXk7 for <oauth@ietfa.amsl.com>; Tue, 7 Apr 2020 21:51:23 -0700 (PDT)
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 4ED6C3A0C1C for <oauth@ietf.org>; Tue, 7 Apr 2020 21:51:23 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0384pJqg017263 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 8 Apr 2020 00:51:21 -0400
Date: Tue, 07 Apr 2020 21:51:18 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: "Peck, Michael A" <mpeck@mitre.org>, "oauth@ietf.org" <oauth@ietf.org>
Message-ID: <20200408045118.GP88064@kduck.mit.edu>
References: <0995BBB3-73E2-4831-B07E-BB5CB5F17AE9@mitre.org> <CA+k3eCTpoOwwTWBqfWHpqeKDo4jGcgU9ockFq17-0W92q-08yg@mail.gmail.com> <20200407035422.GG88064@kduck.mit.edu> <CA+k3eCQCfX8VLt23uxK1hBDPhiA-08R9APvbifv4QQXOvb2atg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+k3eCQCfX8VLt23uxK1hBDPhiA-08R9APvbifv4QQXOvb2atg@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bB3eyZRXJIjnYNaMz2NlwL9E5ps>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-dpop-00 comments
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: Wed, 08 Apr 2020 04:51:26 -0000

On Tue, Apr 07, 2020 at 03:31:09PM -0600, Brian Campbell wrote:
> One of the primary motivations for the proof-of-possession mechanism of
> DPoP being at the application layer was to hopefully enable implementation
> and deployment by regular application developers. A lesson learned from the
> difficulties and lack of adoption around Token Binding was that access to
> TLS exporters is non-existent or prohibitively cumbersome in many
> development environments. Browsers, for example, don't expose any such API
> to javascript. And that's a non-starter here.
> 
> Are there other practical ways to include a server contribution that have
> been overlooked?

the main thing that comes to mind is (basically) an explicti nonce, which
costs an extra round trip unless you get clever.

In particular, "get clever" can be something that amortizes a single extra
round trip across *all* interactions with that server, akin to how ACME
requires a fresh nonce (and signature) for each request (RFC 8555).

-Ben

v2.23.0 | Report a Bug | By Email