Re: [OAUTH-WG] MTLS vs. DPOP

Vittorio Bertocci <Vittorio@auth0.com> Tue, 07 May 2019 15:44 UTC

Return-Path: <vittorio.bertocci@auth0.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 865E0120144 for <oauth@ietfa.amsl.com>; Tue, 7 May 2019 08:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auth0.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 R0vu5rmyU76X for <oauth@ietfa.amsl.com>; Tue, 7 May 2019 08:44:50 -0700 (PDT)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 E444A12011D for <oauth@ietf.org>; Tue, 7 May 2019 08:44:49 -0700 (PDT)
Received: by mail-lf1-x12a.google.com with SMTP id n134so10393049lfn.11 for <oauth@ietf.org>; Tue, 07 May 2019 08:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rO7BdrcqMDIHL5pbPZmbZeTD16MXt4j5wqL0QSZZB6k=; b=Tpa6ep30i0OmXLX5MA5Ks7vt3kLtBBU2sujHdgC0MYeJho3Y5QxIynszPlweuMwR9C XujOEEtb4ZkgctCdIf/s5G5WXVoHxwXkip33CGTP6EReZk4IsHS21/FcqvivjOAMT1dZ HOhdXBVB1tIIjHeM2Q8D929Cui5DgUasoeCH6Fe7ElA4GZ2P+ElY3WUr7xRIsoyC60id 9DEjIrsIwuTCX1+vGM9F+3A34GcaNV+97ur+1YjKJra/5Eeju5S7QKiCfD1QkjqH2HdQ 3mPCSiPi6g+o7gWFBI9yD8daBV2dEsThlcg8MQfeRMFLtIIz56jk7DP0jCuO+Bqiia22 uayA==
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=rO7BdrcqMDIHL5pbPZmbZeTD16MXt4j5wqL0QSZZB6k=; b=Ty4jNJkzxdWO/TAgPTBtW/K+nyiN2I14BIJOuXkC1WEBZ5MqviKzKnoNE8NaxqljaX ZqDsB1c4W3No+9AexVM+D8fSzCY8YyFee4GsI7w5gdnACJkIx0rXg7EHVtrpPcWNGWA6 y3Jipe+fdcZnSNy1QaP6/Q+3H88ASWrx3meO3Vq9rc2KgtLbIYazPDM89w7gAMcHyiyL BbpkjoseGgFE9wWJyH7ZBzZaJ5DhjGe8E39gReMBq4OV0PJA67Gl8O1BTp5rbw8ZRXnN kwnox6g/x7UztOXabHWC+MUjbM4gUtnihVU86E7ro7jY5Bd5GCAQ+tpX91kMuC86vlOo Lf3Q==
X-Gm-Message-State: APjAAAWYTK8X9tDpeo21qSuLllE+fITNWj8R9CnQ3e46kLe9vQCBQQwn bQX3orJ+gcBOvpXjfNaEnuzgfDq17nReLKnwl5LvnQ==
X-Google-Smtp-Source: APXvYqxELKX4NwAqCQsBii2Y9QBNaNWlUsc96NZO65N0L9X2sgMnAN7k0mIYaOrpRd8sqqTjXFl4A8urtLo1ImwEmYs=
X-Received: by 2002:ac2:51a1:: with SMTP id f1mr15580188lfk.129.1557243887782; Tue, 07 May 2019 08:44:47 -0700 (PDT)
MIME-Version: 1.0
References: <DBBPR08MB4539BA4621AC8029AEF4F8C8FA310@DBBPR08MB4539.eurprd08.prod.outlook.com> <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com>
In-Reply-To: <31bec10c-e245-12b4-c092-2928b8e286d7@aol.com>
From: Vittorio Bertocci <Vittorio@auth0.com>
Date: Tue, 07 May 2019 08:44:36 -0700
Message-ID: <CAO_FVe4f3eTJKa1tZjrwkLxnrejX9n+5mU8PJBU5KaRw_TMDzg@mail.gmail.com>
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c2a61105884e188c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/d_WcdI4Gcs7VkBu7b5SHNo-3_A8>
Subject: Re: [OAUTH-WG] MTLS vs. DPOP
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: Tue, 07 May 2019 15:44:54 -0000

To clarify, I wasn’t suggesting we drop one or the other. Both have their
merit and use cases, and both should be developed all the way to standard
IMO. But from some preliminary exploration, it seems unlikely that services
will adopt both at the same time. From the “pr” perspective, having a clear
_default_ answer to the question “how do I add sender constraint
capabilities to my service?” would greatly enhance the chances of getting
something out in the real world quickly, make it possible to interop and
iron out wrinkles, etc etc-
For the general developer populace, at this point “sender constraint”
remains something vaguely exotic and often decisions made on that (like the
ones on the implicit deprecation) are poorly received. Even the ones who
had exposure had been somewhat “burned” by how token binding is going, and
we are in need for something easy to grok and actionable to rekindle
interest IMO. The sooner we can get the concept mainstream the better.

On Tue, May 7, 2019 at 07:13 George Fletcher <gffletch=
40aol.com@dmarc.ietf.org> wrote:

> I don't see them the same at all. With MTLS, the token is bound to the
> transport layer (and the key used to establish that encrypted connection).
> With DPOP, the token is bound to the private key known to the client.
>
> To compromise an MTLS bound token the attacker has to compromise the
> private key. To compromise a DPOP bound token, depending on what HTTP
> request elements are signed, and whether the DPOP is managed as
> one-time-use etc, there are additional attacks. (Ducks head and waits for
> all the real security experts to prove me wrong:)
>
> The deployment models are also different. With MTLS bound tokens the
> clients don't really have to know about the binding because it is
> established at the AS and the deployment of the service manages the cert
> used for the MTLS connection. This is simpler for client development
> (provided the environment is already set up for MTLS everywhere).
>
> I'd strong encourage us to continue supporting both methods.
>
> On 5/7/19 4:25 AM, Hannes Tschofenig wrote:
>
> Hi all,
>
> ?
>
> In the OAuth conference call today Vittorio mentioned that some folks are
> wondering whether DPOP is essentially a superset of MTLS and whether it
> makes sense to only proceed with one solution rather potentially two.
>
> ?
>
> I was wondering whether others in the group have a few about this aspect?
>
> ?
>
> Ciao
>
> Hannes
>
> ?
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
> _______________________________________________
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>