Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

["Richard Backman, Annabelle" <[e-mail]>]

David, Warren, Hannes and others:

The limitations of DPoP and mTLS have been discussed numerous times within the Working Group. Here is a summary of those that I am aware of; others may have additional concerns.

(Though please note first that none of this is to say that DPoP and mTLS are bad or useless – they each are targeted at certain use cases, and they serve those well. They just don't serve every use case well.)

DPoP Limitations:

  1.  Does not support symmetric keys.
  2.  Requires the same key to be used with AS and RSes.
  3.  Does not support multiple valid signing keys.
  4.  Signed content is copied into the JWT and therefore duplicated within the message. This allows for bugs where the verifier fails to check that these values match, or performs that check incorrectly. (e.g., assuming case insensitivity)
  5.  Only covers the method, scheme, host, and path. Allows for additional arbitrary content to be signed, but does not provide any guidance or support for defining interoperable extensions.
  6.  Depends on JWT, which may be a new dependency, particularly for clients that are doing OAuth 2.0 but not OIDC.

mTLS Limitations:

  1.  Requires a single end-to-end TLS connection between client and AS/RS. This often is not the case in modern distributed systems, e.g., TLS may be terminated at a load balancer, or by the hosting platform in the case of a "serverless" application. On the client side, enterprises may have TLS inspection appliances that break the TLS connection.
  2.  Abysmal user experience in the browser. (though that is what DPoP was intended to address, at least initially)

In contrast, Justin's HTTP Message Signatures-based approach:

  1.  Allows for flexibility regarding key selection.
  2.  Allows signing of as much or as little of the HTTP message as is appropriate for the request.
  3.  Does not duplicate signed content.
  4.  Does not depend on JWT, unless you want it to.
  5.  Does not depend on an end-to-end TLS connection, or any other specifics below the HTTP layer.
  6.  Allows servers to use the same signature mechanism for other HTTP signing use cases. (e.g., browser signing authorization cookies, LBs adding a signature over the `X-Forwarded-For` header field)

Note that these concerns regarding use cases not addressed by DPoP and mTLS are not new. Below are excerpts taken from WG meeting notes going back to 2019:


  *   IETF 105<https://datatracker.ietf.org/doc/minutes-105-oauth-201907261000/>:
     *   MTLS is good but not great for browser. TOKBIND has no current browser support. Need solution for browser apps.

     *   [Daniel Fett]: DPOP is hopefully a simple and concise mechanism.

     *   [Brian Campbell]: DPOP came out of a desire for a simplified concise public key mechanism at both the authz and resource server….there isn’t the overhead for symmetric keys.

     *   [Annabelle Backman]: We too find [DPoP] limiting without symmetric as asymmetric can be just too slow.

     *   [John Bradley]: The origin of [DPoP] came from the security workshop specifically focused on applications to do PoP should token binding not come to fruition. We could use web-crypto and create a non-exportable key in the browser. This is why there is no support for symmetric key.

     *   [Mike Jones]: Want to use different POP keys for AT and RT.

     *   [Justin Richer]: I really like this approach. But I agree with Hannes that having a server provided symmetric key is useful.

     *   Roman [Danyliw]: Strongly urge the equities of other groups and surface them.

  *   IETF 106<https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03.pdf>:
     *   Annabelle [Backman]: Would you consider using a HTTP signing solution and not do this
John [Bradley]: ...[DPoP] has limited aspirations than the http signing.

     *   Some discussions on symmetric vs asymmetric encryption and Annabelle is concerned about the scaling and crypto costs. So some folks want both types, this would increase the scope of the effort [for DPoP].

The scope [of DPoP] was to be able to use something with sender constraint for SPA, this is not for broader usage, so this is limited scope not doing what HTTP Signing would be used for. So this needs to be presented as a very focused effort.

     *   Mike [Jones]: The usage of TLS for sender constraint is not deployable

  *   OAuth WG Interim Meeting – 2021-03-15<https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-01-202103151200/>:
     *   Francis [Pouatcha]: DPoP should be by no way a replacement for HTTP signing.

—
Annabelle Backman (she/her)
[e-mail]<mailto:[e-mail]>




On Oct 8, 2021, at 5:38 PM, David Waite <david=[e-mail]<mailto:david=[e-mail]>> wrote:

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



I do not support adopting this work as proposed, with the caveat that I am a co-editor of the DPoP work.

We unfortunately do not have a single approach for PoP which works for all scenarios and deployments, why we have had several proposals and standards such as Token Binding, mutual TLS, and DPoP. There have been other less generalized approaches as well, such as forming signed request and response objects on the channel when one needs end-to-end message integrity or confidentiality.

Each of these has their own capabilities and trade-offs, and their applicability to scenarios where the others falter is why multiple approaches is justified.

The preferred solution for HTTPS resource server access is to leverage MTLS. However, browsers have both poor/nonexistent API to manage ephemeral client keys and poor UX around mutual TLS in general.

DPoP was proposed to attempt a “lightest lift” to provide cryptographic evidence of the sender being involved, so that browsers could protect their tokens from exfiltration by non-exportable, ephemeral keys. In that way, we keep from having to define a completely separate security posture for resource-constraining browser apps.

The motivations for the HTTPSig specification don’t clearly state why it is essential to have another promoted PoP approach. I would expect more prescriptive text about the use case that this is proposed for. In particular, I would love to see an additional use case, outside of DPoP, not solved by MTLS but solved by this proposal.

If it turns out the target between a HTTP Message Signatures and DPoP overlap completely, I suspect we would have the issue of two competing adopted drafts in the working group. I personally do not know the ramifications of such an event. I do not believe there would be consensus on eliminating one, nor would there be a significant reduction in complexity by combining them.

Deferring until HTTPSig is interoperably implemented in the industry gives us concrete motivation in the future to support both.

-DW
_______________________________________________
OAuth mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/oauth