Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature

Denis <denis.ietf@free.fr> Thu, 07 October 2021 09:03 UTC

Return-Path: <denis.ietf@free.fr>
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 D7E973A0B79 for <oauth@ietfa.amsl.com>; Thu, 7 Oct 2021 02:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.719
X-Spam-Level:
X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 sAoFl8uAS82y for <oauth@ietfa.amsl.com>; Thu, 7 Oct 2021 02:03:17 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) (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 709413A0B6B for <oauth@ietf.org>; Thu, 7 Oct 2021 02:03:16 -0700 (PDT)
Received: from [192.168.1.11] ([90.91.41.134]) by smtp.orange.fr with ESMTPA id YPJ2mnEXMFGqtYPJ3mnoxZ; Thu, 07 Oct 2021 11:03:14 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: OWU3ZmVkYWM0M2UwZWM1YifxM2Q3ZDk1YiUzNWJiZTM2MiliMTI0N2YxZmQ=
X-ME-Date: Thu, 07 Oct 2021 11:03:14 +0200
X-ME-IP: 90.91.41.134
To: oauth@ietf.org
References: <CADNypP9QXCEjJmkhBvTHn68kDcJ2Mfg-tSQx1-hvfPoOTXCKzA@mail.gmail.com> <CAGBSGjqasD=eYnsMm7gZB2g+=C4abZoVi7FH4e7EFfgwKdjS8w@mail.gmail.com> <CAD9ie-uH9xGL9orTFxEd=tfhO6Q-S3sDHrQDtU7h0_dr6YeLOg@mail.gmail.com> <EE56CE99-5592-40AF-9BA5-7F3886ED315A@mit.edu> <CAD9ie-t9i1sVLhVhJp-mWSchV_x0b3no7i4qNXvcaQS+8OqCVA@mail.gmail.com> <CAGBSGjrgVbGWwFq6LDX_2Vhv7yQkwtEEjy36GpLj-bN+MtcX-w@mail.gmail.com> <CAD9ie-vJiwBSV71z4_2TJJO7A52mV763XvXmEPsEFgOMFVOwyQ@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <3e3ca312-6c03-d3ea-cf6f-e13ba22a9545@free.fr>
Date: Thu, 07 Oct 2021 11:03:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CAD9ie-vJiwBSV71z4_2TJJO7A52mV763XvXmEPsEFgOMFVOwyQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------76A75374967E8471DA7EC544"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rWyFjuS1wON0HmdAdf240fr4A4s>
Subject: Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature
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: Thu, 07 Oct 2021 09:03:22 -0000

I am not supportive of adoption of this document by the WG /at this time/.

As I said during the last interim meeting, at this time, there is no 
security considerations section, nor a privacy considerations section.

The current draft describes a mechanism but does not state how the 
signing key will be established and / or come from.

 From a security considerations point of view, if the client has the 
control of the private key, it might be able to voluntary transmit
the private key to another client in order to mount a client 
collaborative attack. If the client is unable to transmit the private key
to another client in order to mount a collaborative attack, it might be 
able to perform all the cryptographic computations that
the other client needs. It is important to state which protections (or 
detection) features will be obtained as well as which protections
(or detection) features will not be obtained. A top-down approach is 
currently missing.

 From a privacy considerations point of view, if the same public key is 
used to sign the messages whatever the RS is, this will allow
different RSs to link the requests from the same client. It is important 
to state which protections (or detection) features will be obtained
as well as which protections (or detection) features will not be obtained.

Let us wait to have both the security considerations section and the 
privacy considerations section written,
before adopting this draft as a WG document.

Denis


> Remember token binding? It was a stable draft. The OAuth WG spent a 
> bunch of cycles building on top of token binding, but token binding 
> did not get deployed, so no token binding for OAuth.
>
> As I mentioned, I think Justin and Annabelle (and anyone else 
> interested) can influence HTTP Sig to cover OAuth use cases.
>
> /Dick
> ᐧ
>
> On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <aaron@parecki.com 
> <mailto:aaron@parecki.com>> wrote:
>
>     This actually seems like a great time for the OAuth group to start
>     working on this more closely given the relative stability of this
>     draft as well as the fact that it is not yet an RFC. This is a
>     perfect time to be able to influence the draft if needed,
>     rather than wait for it to be finalized and then have to find a
>     less-than-ideal workaround for something unforeseen.
>
>     Aaron
>
>     On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt <dick.hardt@gmail.com
>     <mailto:dick.hardt@gmail.com>> wrote:
>
>         I meant it is not yet adopted as an RFC.
>
>         To be clear, I think you are doing great work on the HTTP Sig
>         doc, and a number of concerns I have with HTTP signing have
>         been addressed => I just think that doing work in the OAuth WG
>         on a moving and unproven draft in the HTTP WG is not a good
>         use of resources in the OAuth WG at this time.
>
>
>         ᐧ
>
>         On Wed, Oct 6, 2021 at 2:20 PM Justin Richer <jricher@mit.edu
>         <mailto:jricher@mit.edu>> wrote:
>
>             > HTTP Sig looks very promising, but it has not been
>             adopted as a draft
>
>             Just to be clear, the HTTP Sig draft is an official
>             adopted document of the HTTP Working Group since about a
>             year ago. I would not have suggested we depend on it for a
>             document within this WG otherwise.
>
>              — Justin
>
>>             On Oct 6, 2021, at 5:08 PM, Dick Hardt
>>             <dick.hardt@gmail.com <mailto:dick.hardt@gmail.com>> wrote:
>>
>>             I am not supportive of adoption of this document at this
>>             time.
>>
>>             I am supportive of the concepts in the document. Building
>>             upon existing, widely used, proven security mechanisms
>>             gives us better security.
>>
>>             HTTP Sig looks very promising, but it has not been
>>             adopted as a draft, and as far as I know, it is not
>>             widely deployed.
>>
>>             We should wait to do work on extending HTTP Sig for OAuth
>>             until it has stabilized and proven itself in the field.
>>             We have more than enough work to do in the WG now, and
>>             having yet-another PoP mechanism is more likely to
>>             confuse the community at this time.
>>
>>             An argument to adopt the draft would be to ensure HTTP
>>             Sig can be used in OAuth.
>>             Given Justin and Annabelle are also part of the OAuth
>>             community, I'm sure they will be considering how HTTP Sig
>>             can apply to OAuth, so the overlap is serving us already.
>>
>>             /Dick
>>
>>
>>             ᐧ
>>
>>             On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki
>>             <aaron@parecki.com <mailto:aaron@parecki.com>> wrote:
>>
>>                 I support adoption of this document.
>>
>>                 - Aaron
>>
>>                 On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef
>>                 <rifaat.s.ietf@gmail.com
>>                 <mailto:rifaat.s.ietf@gmail.com>> wrote:
>>
>>                     All,
>>
>>                     As a followup on the interim meeting today, this
>>                     is a *call for adoption *for the *OAuth Proof of
>>                     Possession Tokens with HTTP Message
>>                     Signature* draft as a WG document:
>>                     https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/
>>                     <https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/>
>>
>>                     Please, provide your feedback on the mailing list
>>                     by*October 20th*.
>>
>>                     Regards,
>>                      Rifaat & Hannes
>>
>>                     _______________________________________________
>>                     OAuth mailing list
>>                     OAuth@ietf.org <mailto:OAuth@ietf.org>
>>                     https://www.ietf.org/mailman/listinfo/oauth
>>                     <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>                 _______________________________________________
>>                 OAuth mailing list
>>                 OAuth@ietf.org <mailto:OAuth@ietf.org>
>>                 https://www.ietf.org/mailman/listinfo/oauth
>>                 <https://www.ietf.org/mailman/listinfo/oauth>
>>
>>             _______________________________________________
>>             OAuth mailing list
>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>             https://www.ietf.org/mailman/listinfo/oauth
>>             <https://www.ietf.org/mailman/listinfo/oauth>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth