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

[Neil Madden <[e-mail]>]

Thanks Vladimir,

Responses below

> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <[e-mail]> wrote:
> 
> 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

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
> 
> 
>>> 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.
>> I’d be interested to hear thoughts and discussion on the list prior to
>> any discussion at an interim meeting.
>> — Neil