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

Vladimir Dzhuvinov <vladimir@connect2id.com> Sat, 08 August 2020 09:39 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FA3A09E4 for <oauth@ietfa.amsl.com>; Sat, 8 Aug 2020 02:39:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.844
X-Spam-Level:
X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGTZwBYcTbaY for <oauth@ietfa.amsl.com>; Sat, 8 Aug 2020 02:39:57 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net [173.201.193.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4EA3A09D9 for <oauth@ietf.org>; Sat, 8 Aug 2020 02:39:57 -0700 (PDT)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 4LKVk8iORAJJp4LKWkIeQ6; Sat, 08 Aug 2020 02:39:57 -0700
X-CMAE-Analysis: v=2.3 cv=Sd6JicZu c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=q0rX5H01Qin5IyBaTmIA:9 a=48vgC7mUAAAA:8 a=fxrcP2pIblrs7K5vFycA:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
To: oauth@ietf.org
References: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Autocrypt: addr=vladimir@connect2id.com; prefer-encrypt=mutual; keydata= mQENBFQZaoEBCACnP2YMDex9fnf+niLglTHGKuoypUSVKPQeKDHHeFQVzhRke+HBEZBwmA9T kZ+kEhyrNqibDPkPYVPmo23tM8mbNcTVQqpmN7NwgMpqkqcAqNsIyBtt09DjWOQVm57A3K+y uXI7SdNErdt79p2xQseOhqSC9+LgWuyh+mZsl2oFD4glFFfKSCMp2jATXrAMeGzigTnW+Xe0 tRzrwFN9zqykKxhUq9oHg1cNvoDtfxgsc9ysVHbxM/PM8o9lgj3YTQwKMBcCFclTqohji7ML fQ08eQo+acKTwC1WRzeLt9PknGt3C4TmvdCl0c1BQTTTNiF96Hu4kbaiBIbsfxJOR8+VABEB AAG0LFZsYWRpbWlyIER6aHV2aW5vdiA8dmxhZGltaXJAY29ubmVjdDJpZC5jb20+iQE+BBMB AgAoBQJUGWqBAhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRAZ0vUyOqri Ql62B/wOO0s2JC/QvO6w9iSsRhCOa/JZi+wO+l01V7eGCQ1cYf1W26Y7iKiUlY4/Kz+cr69D pMtkv3UpDTGejKEfspLUxz5Vo3T4oAKbTtNtVIZL/XxH3/JhJ719Jj4eLoe9/djKkGYTX2O5 bMk8TpO1DDjbIw4r9XKI9ZIk96zlKnZvrg7Ho7oOl0ZIf8AzcvdqZEUogDwyr8uwOU+jIyux mOTthepBzXCNjjBjnc8I1//9YppAIaGJ5nnXelVVD1/dyOszogervzFNANEIOvNvCd9G5u4e s7qkDKWKY7/Lj1tF+tMrDTrOh6JqUKbGNeTUB8DlPvIoNyqHUYfBELdpw1Nd
Organization: Connect2id Ltd.
Message-ID: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com>
Date: Sat, 8 Aug 2020 12:39:55 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <0DEE1AC7-2EA7-420F-B0B5-6F96A3D04D1C@forgerock.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080700070207000501000009"
X-CMAE-Envelope: MS4wfFfkoTQWvrpzuTm9KBzxG8du3umnnH//eOYFUeHfbixKgwPXxENYw4g5Fx+mv6bncKGn45XPsmzpVUQTZsl/Ur4eDPgvp2mCF/9xq1KAPIih4lCSuPZg /y6luAT1fXN1eiKMs7BdA7zBrrw/x2wouh6wuuwsi9oDkPdule8T3LGs
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/9VPa9cEcjdxkZNHi90cK-rqK7KE>
Subject: Re: [OAUTH-WG] ECDH-1PU encryption algorithm
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Aug 2020 09:39:59 -0000

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