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

[Neil Madden <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 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 [e-mail] <mailto:[e-mail]>, whose purpose is to find
> homes for new work.
> 
> 
> - m&m
> 
> Matthew A. Miller
> On 20/08/10 11:38, Vladimir Dzhuvinov wrote:
>> On 10/08/2020 11:28, Neil Madden wrote:
>>> 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?
>> 
>> 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
>>>> 
>>>> 
>>>>>> 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
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>