Subject: [OAUTH-WG] DPoP followup II: confirmation style

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Dec 2020 15:28:37 -0700

There were a few items discussed somewhat during the recent interim
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth>
that I committed to bringing back to the list. The slide below (also
available with some typos and omitted words as slide #18 from the interim
presentation
<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>)
is the second one. To summarize (by basically repeating the content of the
slide): It’s been suggested that, for resource access, having the JWK in
the header of the DPoP proof JWT makes it too easy to just use that key to
validate the signature and miss checking the binding to the AT’s cnf/jkt
hash, which undermines the value of doing the binding in the first place.
As I see it, there are two options here and I'd like to gauge WG consensus
on which to move forward with.

   1. It’s fine as is (AS/RS symmetry is nice, it's the same way
   confirmation works in MTLS/TB, and the binding check is kinda fundamental
   to the whole thing so it's not unreasonable to expect implementers to do it)
   2. For resource access, put the full JWK in the AT’s confirmation and
   omit it from the proof (less error prone, no hash function needed for
   confirmation, somewhat less data overall between the two artifacts)

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Filip Skokan <[email-masked]>
Date: Thu, 3 Dec 2020 10:42:35 +0100

Hi Brian, everyone,

implementers always have many ways to mess up if they don't follow the
normative requirements and verification steps we spell out for them in the
document - in dpop's case they could e.g. accept HMAC signed tokens with an
`oct` key.

Pushing the JWK in a JWT Access Token will also increase its size, in case
of RSA keys by a lot, we could say we recommend to use ES* or EdDSA keys
when JWT AT size is a concern but then EdDSA is not available in Web
Cryptography API and the available ES curves have some negative energy
<https://safecurves.cr.yp.to/> around them so it would feel weird
recommending them, better to stick our head in the sand for this one.

I'm in favour of leaving the confirmation style as-is.

Best,
*Filip*

On Wed, 2 Dec 2020 at 23:29, Brian Campbell <bcampbell=
[email-masked]> wrote:

> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Neil Madden <[email-masked]>
Date: Thu, 3 Dec 2020 11:00:14 +0000

Strongly in favour of 2.

I think history shows that successful standards make security checks hard to get wrong rather than merely easy to get right.

— Neil

> On 2 Dec 2020, at 22:28, Brian Campbell <bcampbell=[email-masked]> wrote:
> 
> There were a few items discussed somewhat during the recent interim <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> that I committed to bringing back to the list. The slide below (also available with some typos and omitted words as slide #18 from the interim presentation <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>) is the second one. To summarize (by basically repeating the content of the slide): It’s been suggested that, for resource access, having the JWK in the header of the DPoP proof JWT makes it too easy to just use that key to validate the signature and miss checking the binding to the AT’s cnf/jkt hash, which undermines the value of doing the binding in the first place. As I see it, there are two options here and I'd like to gauge WG consensus on which to move forward with. 
> It’s fine as is (AS/RS symmetry is nice, it's the same way confirmation works in MTLS/TB, and the binding check is kinda fundamental to the whole thing so it's not unreasonable to expect implementers to do it)
> For resource access, put the full JWK in the AT’s confirmation and omit it from the proof (less error prone, no hash function needed for confirmation, somewhat less data overall between the two artifacts)
> 
> 
> 
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked]

-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>

---

From: <[email-masked]>
Date: Fri, 4 Dec 2020 00:54:46 +0000

Hi Brian, everyone

The option 2 makes sense to me, because I think the DPoP Proof to AS and the one
to RS play different roles. Maybe they should even have different names.
However, AS/RS symmetry of option 1 is also attractive from the viewpoint of
an implementer.

I think this topic is related to the question of "followup I: freshness and
coverage of signature". The option 2 for the followup I will also break AS/RS
symmetry. If we choose the option 2 for followup I, I think we might as well
choose the option 2 for followup II, too.

Toshio Ito

From: OAuth <[email-masked]> On Behalf Of Brian Campbell
Sent: Thursday, December 3, 2020 7:29 AM
To: oauth <[email-masked]>
Subject: [OAUTH-WG] DPoP followup II: confirmation style

There were a few items discussed somewhat during the recent interim<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> that I committed to bringing back to the list. The slide below (also available with some typos and omitted words as slide #18 from the interim presentation<https://datatracker.ietf.org/meeting/interim-2020-oauth-16/materials/slides-interim-2020-oauth-16-sessa-dpop-01.pdf>) is the second one. To summarize (by basically repeating the content of the slide): It’s been suggested that, for resource access, having the JWK in the header of the DPoP proof JWT makes it too easy to just use that key to validate the signature and miss checking the binding to the AT’s cnf/jkt hash, which undermines the value of doing the binding in the first place. As I see it, there are two options here and I'd like to gauge WG consensus on which to move forward with.

  1.  It’s fine as is (AS/RS symmetry is nice, it's the same way confirmation works in MTLS/TB, and the binding check is kinda fundamental to the whole thing so it's not unreasonable to expect implementers to do it)
  2.  For resource access, put the full JWK in the AT’s confirmation and omit it from the proof (less error prone, no hash function needed for confirmation, somewhat less data overall between the two artifacts)

CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Dec 2020 14:37:59 -0700

> choose the option 2 for followup II, too.

 I've had similar thoughts, for whatever it's worth.