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

Filip Skokan <panva.ip@gmail.com> Mon, 10 August 2020 16:01 UTC

Return-Path: <panva.ip@gmail.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 9FB7C3A07C8 for <oauth@ietfa.amsl.com>; Mon, 10 Aug 2020 09:01:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 wqalNFQTZYAe for <oauth@ietfa.amsl.com>; Mon, 10 Aug 2020 09:00:59 -0700 (PDT)
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAC03A07C7 for <oauth@ietf.org>; Mon, 10 Aug 2020 09:00:59 -0700 (PDT)
Received: by mail-yb1-xb2c.google.com with SMTP id g3so2397908ybc.3 for <oauth@ietf.org>; Mon, 10 Aug 2020 09:00:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bEOAnj1YkifZr1wvs1BKS9rsP8e19n7ATtedpWCL0tk=; b=TLn698IXOD/wt3GxUkB/Jcvk+mFOiW3i+RGwMxLe71xc9g90yJCwJZMcpc93CovDNV zvotx5bE8hvT2hR7AlzsC0CnSaIf7fkKCOM32yaMMnEvKbKCLCHdfRhYJ2pJCkXXhn3Q +ofyGzKiPJowcE+m9wth+FZca3v3fM7suQ/ulTaJIPYV+2cLQKiKoljeZpgrLjCVrwZR n5zkDYyZx9HtlJy0HmJjIFpuOQizN9z0w3nOy8pkNU9rSQYo0PRqbeY0sDvnkeVBVHrA AgC++6OdPAj9gnlDNThr0AChiNk9gf6yXK6LrxKnhUO8funMBVQvo3jqFTEb2SUWd+cB ub/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bEOAnj1YkifZr1wvs1BKS9rsP8e19n7ATtedpWCL0tk=; b=HR++IpAITsTsoPVMAcfk9Dzsr/Fsc/OExOcGL6ZDyGEzgGMP+tlOOGP6iFvoSEuJ2b OC4qdigJEWTzhZf1hk+/V9D1JxkGpOV6SfbZN23lqOfYGXWKDsrGBHSq3aYJGozg+/BR OO7EajhbqcLr1otxlITME34luqezF62bsYKsBO6EkCdbxdFnga6cWsbURaTemANH4qNR l/AnhTMMvMt2lV8kiFaOB1hl6Q9NMOa/g5Q4ktcj+15GMz3aJuAEXhuPWHO1Ced/vpFD cktWVbfx0XaqALFZhdvGU++94TXAbztjcf9gqoxJJrCc7nz8Fp1D4hLrnDXcOu33Nm7h qJ+g==
X-Gm-Message-State: AOAM531uDEDuWfo7h/P6NNiDqJrTVr3BKlxVodI1avKoW42Nmi0ks6uC bH5uMDWdROmoHUH6o7Y8enuSCXNUjq3Fk+dBPQ==
X-Google-Smtp-Source: ABdhPJynopxpHNaVYmDg1S4TRbTGctFqBEyXpyl59YJNNF5lp4Fcx5rOMVYRQNB0OxD8a/uHw3dZdd1ztUD/W0ElzqM=
X-Received: by 2002:a25:c743:: with SMTP id w64mr38285669ybe.127.1597075258876; Mon, 10 Aug 2020 09:00:58 -0700 (PDT)
MIME-Version: 1.0
References: <51424c05-3199-0caf-65ea-6d7a4433c9b9@connect2id.com> <A3AC8EAF-97B3-4778-8F3D-206350E7DAD3@forgerock.com>
In-Reply-To: <A3AC8EAF-97B3-4778-8F3D-206350E7DAD3@forgerock.com>
From: Filip Skokan <panva.ip@gmail.com>
Date: Mon, 10 Aug 2020 18:00:22 +0200
Message-ID: <CALAqi_9zoH-S9i6CgLRuKDX3sSBPtVm5fsmd8Riy7Ydk-P7Acw@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007c25a105ac880f53"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/2QZFTsqH5zV2gypZ8Gbt_TZ6wE8>
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 16:01:02 -0000

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 <neil.madden@forgerock.com> 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?
>
> >
> > 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>