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

Vladimir Dzhuvinov <vladimir@connect2id.com> Mon, 10 August 2020 17:38 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 064C03A0B8E for <oauth@ietfa.amsl.com>; Mon, 10 Aug 2020 10:38:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.823
X-Spam-Level:
X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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=no 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 K8WmkLAGyvYo for <oauth@ietfa.amsl.com>; Mon, 10 Aug 2020 10:38:35 -0700 (PDT)
Received: from p3plsmtpa07-07.prod.phx3.secureserver.net (p3plsmtpa07-07.prod.phx3.secureserver.net [173.201.192.236]) (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 A81033A0B8F for <oauth@ietf.org>; Mon, 10 Aug 2020 10:38:35 -0700 (PDT)
Received: from [192.168.88.250] ([94.155.17.31]) by :SMTPAUTH: with ESMTPSA id 5Bknkbgl8lsQb5Bkok3IWi; Mon, 10 Aug 2020 10:38:34 -0700
X-CMAE-Analysis: v=2.3 cv=KaGsTjQD c=1 sm=1 tr=0 a=+I3yL00+yDwT8KNLgfs+4A==:117 a=+I3yL00+yDwT8KNLgfs+4A==:17 a=9cW_t1CCXrUA:10 a=q0rX5H01Qin5IyBaTmIA:9 a=__SxRlIrAAAA:8 a=48vgC7mUAAAA:8 a=ZhbJ1iEMXRcCrf8ZpzMA:9 a=QEXdDO2ut3YA:10 a=D8lnhvtxf0AONpHuB7QA:9 a=ZVk8-NSrHBgA:10 a=30ssDGKg3p0A:10 a=H5r4HjhRfVyZ-DhAOYba:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: vladimir@connect2id.com
Cc: oauth@ietf.org
References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> <A3AC8EAF-97B3-4778-8F3D-206350E7DAD3@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: <e8d68d47-54cc-fcb8-9bcf-c1904608b584@connect2id.com>
Date: Mon, 10 Aug 2020 20:38:32 +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: <A3AC8EAF-97B3-4778-8F3D-206350E7DAD3@forgerock.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms040902020200030403090204"
X-CMAE-Envelope: MS4wfKdCOQLJG6G6sX1E/7Ev61pDZ0p+yuwsWNA3oRaD6//EtgmMAJbwM41hE1S3//2vd52i+x2Vcf+XJFAIZu6iewwkb6GdtyfutE2pMAWxxVuqrplNetQH Bqr8FjDKLnce3xvm8l3GEBEfsfnEEHt4gfAhAdGoQb79D/MEXYKkId0w
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/jYCoGvQ4Pa4x_HH76yp3gZnQrpw>
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: Mon, 10 Aug 2020 17:38:37 -0000

On 10/08/2020 11:28, Neil Madden wrote:
> Thanks Vladimir,
>
> Responses below
>
>> On 8 Aug 2020, at 10:40, Vladimir Dzhuvinov <vladimir@connect2id.com> 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

-- 
Vladimir Dzhuvinov