Subject: [OAUTH-WG] ECDH-1PU encryption algorithm

From: Neil Madden <[email-masked]>
Date: Wed, 5 Aug 2020 11:01:55 +0100

Hi all,

You may remember me from such I-Ds as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03 <https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03>, which proposes adding a new encryption algorithm to JOSE. I’d like to reserve a bit of time to discuss it at one of the upcoming interim meetings.

The basic idea is that in many cases in OAuth and OIDC you want to ensure both confidentiality and authenticity of some token - for example when transferring an ID token containing PII to the client through the front channel, or for access tokens intended to be handled by a specific RS without online token introspection (such as the JWT access token draft). If you have a shared secret key between the AS and the client/RS then you can use symmetric authenticated encryption (alg=dir or alg=A128KW etc). But if you need to use public key cryptography then currently you are limited to a nested signed-then-encrypted JOSE structure, which produces much larger token sizes.

The draft adds a new “public key authenticated encryption” mode based on ECDH in the NIST standard “one-pass unified” model. The primary advantage for OAuth usage is that the tokens produced are more compact compared to signing+encryption (~30% smaller for typical access/ID token sizes in compact serialization). Performance-wise, it’s roughly equivalent. I know that size concerns are often a limiting factor in choosing whether to encrypt tokens, so this should help.

In terms of implementation, it’s essentially just a few extra lines of code compared to an ECDH-ES implementation. (Some JOSE library APIs might need an adjustment to accommodate the extra private key needed for encryption/public key for decryption).

I’ve received a few emails off-list from people interested in using it for non-OAuth use-cases such as secure messaging applications. I think these use-cases can be accommodated without significant changes, so I think the OAuth WG would be a good venue for advancing this.

I’d be interested to hear thoughts and discussion on the list prior to any discussion at an interim meeting.

— Neil

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Sat, 8 Aug 2020 12:39:55 +0300

Hi Neil,

I definitely like the elegance of the proposed alg for JOSE, it provides
something that isn't currently available in the various classes of algs
made standard in JOSE.

I also wanted to ask what's happening with AES SIV for JOSE, if there's
traction / feedback / support there as well?

https://tools.ietf.org/html/draft-madden-jose-siv-mode-02

Vladimir

On 05/08/2020 13:01, Neil Madden wrote:
> Hi all,
>
> You may remember me from such I-Ds
> as https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which
> proposes adding a new encryption algorithm to JOSE. I’d like to
> reserve a bit of time to discuss it at one of the upcoming interim
> meetings.
>
> The basic idea is that in many cases in OAuth and OIDC you want to
> ensure both confidentiality and authenticity of some token - for
> example when transferring an ID token containing PII to the client
> through the front channel, or for access tokens intended to be handled
> by a specific RS without online token introspection (such as the JWT
> access token draft). If you have a shared secret key between the AS
> and the client/RS then you can use symmetric authenticated encryption
> (alg=dir or alg=A128KW etc). But if you need to use public key
> cryptography then currently you are limited to a nested
> signed-then-encrypted JOSE structure, which produces much larger token
> sizes.
>
> The draft adds a new “public key authenticated encryption” mode based
> on ECDH in the NIST standard “one-pass unified” model. The primary
> advantage for OAuth usage is that the tokens produced are more compact
> compared to signing+encryption (~30% smaller for typical access/ID
> token sizes in compact serialization). Performance-wise, it’s roughly
> equivalent. I know that size concerns are often a limiting factor in
> choosing whether to encrypt tokens, so this should help.
>
> In terms of implementation, it’s essentially just a few extra lines of
> code compared to an ECDH-ES implementation. (Some JOSE library APIs
> might need an adjustment to accommodate the extra private key needed
> for encryption/public key for decryption).
>
> I’ve received a few emails off-list from people interested in using it
> for non-OAuth use-cases such as secure messaging applications. I think
> these use-cases can be accommodated without significant changes, so I
> think the OAuth WG would be a good venue for advancing this.
>

---

From: Dave Tonge <[email-masked]>
Date: Mon, 10 Aug 2020 08:17:47 +0200

Hi Neil

I'd be interested in seeing this draft discussed.

Dave

On Wed, 5 Aug 2020 at 12:02, Neil Madden <[email-masked]> wrote:

> Hi all,
>
> You may remember me from such I-Ds as
> https://tools.ietf.org/html/draft-madden-jose-ecdh-1pu-03, which proposes
> adding a new encryption algorithm to JOSE. I’d like to reserve a bit of
> time to discuss it at one of the upcoming interim meetings.
>
> The basic idea is that in many cases in OAuth and OIDC you want to ensure
> both confidentiality and authenticity of some token - for example when
> transferring an ID token containing PII to the client through the front
> channel, or for access tokens intended to be handled by a specific RS
> without online token introspection (such as the JWT access token draft). If
> you have a shared secret key between the AS and the client/RS then you can
> use symmetric authenticated encryption (alg=dir or alg=A128KW etc). But if
> you need to use public key cryptography then currently you are limited to a
> nested signed-then-encrypted JOSE structure, which produces much larger
> token sizes.
>
> The draft adds a new “public key authenticated encryption” mode based on
> ECDH in the NIST standard “one-pass unified” model. The primary advantage
> for OAuth usage is that the tokens produced are more compact compared to
> signing+encryption (~30% smaller for typical access/ID token sizes in
> compact serialization). Performance-wise, it’s roughly equivalent. I know
> that size concerns are often a limiting factor in choosing whether to
> encrypt tokens, so this should help.
>
> code compared to an ECDH-ES implementation. (Some JOSE library APIs might
> need an adjustment to accommodate the extra private key needed for
> encryption/public key for decryption).
>
> I’ve received a few emails off-list from people interested in using it for
> non-OAuth use-cases such as secure messaging applications. I think these
> use-cases can be accommodated without significant changes, so I think the
> OAuth WG would be a good venue for advancing this.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

-- 
Dave Tonge
CTO
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
t: +44 (0)117 280 5120

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
Limited which is authorised and regulated by the Financial Conduct
Authority ("FCA"). Moneyhub Financial Technology is entered on the
Financial Services Register (FRN 809360) at fca.org.uk/register.
Moneyhub Financial
Technology is registered in England & Wales, company registration number
06909772 .
Moneyhub Financial Technology Limited 2018 ©

DISCLAIMER: This email (including any attachments) is subject to copyright,
and the information in it is confidential. Use of this email or of any
information in it other than by the addressee is unauthorised and unlawful.
Whilst reasonable efforts are made to ensure that any attachments are
virus-free, it is the recipient's sole responsibility to scan all
attachments for viruses. All calls and emails to and from this company may
be monitored and recorded for legitimate purposes relating to this
company's business. Any opinions expressed in this email (or in any
attachments) are those of the author and do not necessarily represent the
opinions of Moneyhub Financial Technology Limited or of any other group
company.

-- 

Moneyhub Enterprise is a trading style of Moneyhub Financial Technology 
Limited which is authorised and regulated by the Financial Conduct 
Authority ("FCA"). Moneyhub Financial Technology is entered on the 
Financial Services Register (FRN 809360) at https://register.fca.org.uk/ 
<https://register.fca.org.uk/>. Moneyhub Financial Technology is registered 
in England & Wales, company registration number 06909772. Moneyhub 
Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, 
Temple Quay, 1 Friary, Bristol, BS1 6EA. 

DISCLAIMER: This email 
(including any attachments) is subject to copyright, and the information in 
it is confidential. Use of this email or of any information in it other 
than by the addressee is unauthorised and unlawful. Whilst reasonable 
efforts are made to ensure that any attachments are virus-free, it is the 
recipient's sole responsibility to scan all attachments for viruses. All 
calls and emails to and from this company may be monitored and recorded for 
legitimate purposes relating to this company's business. Any opinions 
expressed in this email (or in any attachments) are those of the author and 
do not necessarily represent the opinions of Moneyhub Financial Technology 
Limited or of any other group company.

---

From: Neil Madden <[email-masked]>
Date: Mon, 10 Aug 2020 09:28:55 +0100

Thanks Vladimir,

Responses below

> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
> Hi Neil,
> 

Thanks for bringing this up. I’ve not received much feedback about this one, and I haven’t been very good at pushing it. If there is interest then I’d certainly be interested in bringing this forward too. 

That draft might be a better fit for eg the COSE WG though, which could then also register identifiers for JOSE. What do you think?

---

From: Filip Skokan <[email-masked]>
Date: Mon, 10 Aug 2020 18:00:22 +0200

Hi Neil,

I'm interested in seeing both AES SIV and ECDH-1PU for JOSE. Not sure how
to go about it tho since JOSE is a concluded WG.

Out of curiosity, why is it a concluded WG? Did IETF/JOSE WG not consider
the need to further maintain/expand the JOSE algorithms as time goes on?

S pozdravem,
*Filip Skokan*

On Mon, 10 Aug 2020 at 10:29, Neil Madden <[email-masked]> wrote:

> Thanks for bringing this up. I’ve not received much feedback about this
> one, and I haven’t been very good at pushing it. If there is interest then
> I’d certainly be interested in bringing this forward too.
>
> That draft might be a better fit for eg the COSE WG though, which could
> then also register identifiers for JOSE. What do you think?
>
> >
> > Vladimir
> >
> >

---

From: Dick Hardt <[email-masked]>
Date: Mon, 10 Aug 2020 10:27:23 -0700

I'm supportive of this work.

It is not clear that it is in the charter of the OAuth WG.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 10 Aug 2020 20:38:32 +0300

> That draft might be a better fit for eg the COSE WG though, which could then also register identifiers for JOSE. What do you think?

If the COSE is the "proper" WG to get the spec completed and the algs
registered, then let it be COSE. We can continue the conversation there.
I support both drafts.

-- 
Vladimir Dzhuvinov

---

From: "Matthew A. Miller" <[email-masked]>
Date: Mon, 10 Aug 2020 13:39:52 -0600

Hi all,

I have not read these drafts yet, so please forgive me if speaking out
of turn.

Speaking as co-chair of COSE WG, we're intermittently discussing a
recharter, and accepting new algorithms without recharter has consensus
so far.  Note, though, that the COSE WG is focused on COSE and not JOSE.
 Not to say the work couldn't be done there, but if there's little-to-no
interest in COSE then it is not likely to make progress.

Also, if there's not a clear place to progress work, I would strongly
suggest bringing it up on [email-masked], whose purpose is to find
homes for new work.

- m&m

Matthew A. Miller

---

From: Neil Madden <[email-masked]>
Date: Tue, 11 Aug 2020 11:33:51 +0100

I think the SIV draft is well suited to COSE - it shares many similar properties to CCM, which is widely used in embedded/IoT applications (and COSE). The misuse resistance is also particularly appealing in those environments (indeed, I created the draft to support some IoT activity at ForgeRock). For example, Teserakt (https://teserakt.io <https://teserakt.io/>) use SIV mode in their IoT platform [1].

The ECDH-1PU draft is also potentially interesting for constrained environments, given that it eliminates the need for a separate signature so would provide a reduction in code size. COSE already has an ECDH-SS mode which is also authenticated, so this would compliment that with some stronger security properties.

I think therefore that the COSE WG could be a natural home, so I will send a message there to see if there is interest and otherwise take them to secdispatch. The drafts can then register identifiers for COSE and JOSE at the same time.

[1]: https://teserakt-io.github.io/e4-doc/specifications/cryptography-primitives/#authenticated-encryption <https://teserakt-io.github.io/e4-doc/specifications/cryptography-primitives/#authenticated-encryption> 

— Neil

> On 10 Aug 2020, at 20:39, Matthew A. Miller <[email-masked]> wrote:
> 
> Hi all,
> 
> suggest bringing it up on [email-masked] <mailto:[email-masked]>, whose purpose is to find
> homes for new work.
> 
> 
> - m&m
> 
> Matthew A. Miller
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>