Re: [OAUTH-WG] New podcast on identity specifications

Denis <denis.ietf@free.fr> Thu, 24 September 2020 07:39 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 5D7B83A08D8 for <oauth@ietfa.amsl.com>; Thu, 24 Sep 2020 00:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.398, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 7Vz9wvBPtdth for <oauth@ietfa.amsl.com>; Thu, 24 Sep 2020 00:39:52 -0700 (PDT)
Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E96A3A08D7 for <oauth@ietf.org>; Thu, 24 Sep 2020 00:39:51 -0700 (PDT)
Received: from [192.168.1.11] ([90.79.49.68]) by mwinf5d51 with ME id Xjfo2300E1UGgdm03jfodF; Thu, 24 Sep 2020 09:39:49 +0200
X-ME-Helo: [192.168.1.11]
X-ME-Auth: ZGVuaXMucGlua2FzQG9yYW5nZS5mcg==
X-ME-Date: Thu, 24 Sep 2020 09:39:49 +0200
X-ME-IP: 90.79.49.68
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Vittorio Bertocci <vittorio.bertocci@auth0.com>, Vladimir Dzhuvinov <vladimir@connect2id.com>, oauth <oauth@ietf.org>
References: <MWHPR19MB150106AF452F2C06009E0239AE3A0@MWHPR19MB1501.namprd19.prod.outlook.com> <8dbb18c5-803e-b5a9-02b0-1152bd6ec7ed@connect2id.com> <67453f19-025a-0a05-e5eb-f56ee4127646@free.fr> <CA+k3eCTyvZRHMiXqgkrJk1bf3SoTe84APKrtiNRZ0Ty1jCQwzA@mail.gmail.com>
From: Denis <denis.ietf@free.fr>
Message-ID: <275914bc-ec27-ecb4-3f7d-cd2e2ab8a9ce@free.fr>
Date: Thu, 24 Sep 2020 09:39:47 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CA+k3eCTyvZRHMiXqgkrJk1bf3SoTe84APKrtiNRZ0Ty1jCQwzA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------2858BF6EA96DBC86395251AC"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/P-lvMowrICFTig3ogFcHT8dDV2Q>
Subject: Re: [OAUTH-WG] New podcast on identity specifications
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, 24 Sep 2020 07:39:54 -0000

Hello  Brian,

The text was not mentioning explicitly draft-ietf-oauth-dpop-01. While 
re-reading the text, it only appears in a link.

I am NOT arguing that collaborationattacks are something that DPoP is 
expected to address.
I am arguing that DPoP should mention in its Security Considerations 
section that collaborationattacks are something that DPoP does not address.

At the moment, section 9 (Security Considerations) of 
draft-ietf-oauth-dpop-01 is not conformant to RFC 3552 (Guidelines for 
Writing RFC Text
on Security Considerations), since section 5 from RFC 3552 states:

    Authors MUST describe

       1.   which attacks are out of scope (and why!)
       2.   which attacks are in-scope
             2.1  and the protocol is susceptible to
             2.2  and the protocol protects against

Denis


> Hello Denis,
>
> The most recent version of the DPoP draft is not 
> draft-fett-oauth-dpop-04 but rather draft-ietf-oauth-dpop-01, which 
> doesn't expire until November. I realize that the naming and 
> versioning conventions of IETF documents are a bit esoteric and can 
> lend themselves to such mistakes. But someone who insists on making 
> unhelpful criticism of said documents should probably be more mindful 
> of such details.
>
> This WG (and it's not the only WG where this has happened) has 
> repeatedly confirmed the rough consensus that these so-called 
> collaborationattacks are not something that DPoP, or any of the other 
> documents you've said the same about, is expected to address. Nor that 
> there is even reason enough to think that readers need to be told so. 
> Your personal enthusiasm for the topic does not change that and 
> doesn't change the fundamental nature of how OAuth works.
>
> I am sorry to hear that you felt the podcast was too long. I can 
> certainly empathize with feeling like one's time has been wasted.
>
>
>
>
> On Wed, Sep 23, 2020 at 3:38 AM Denis <denis.ietf@free.fr 
> <mailto:denis.ietf@free.fr>> wrote:
>
>     Hello Brian and Vittorio,
>
>     I have two observations:
>
>       * draft-fett-oauth-dpop-04 which is the last version expired on
>         5 September 2020,
>       * the podcast as well as draft-fett-oauth-dpop-04 omit to
>         mention the client/user collaborative attack against which
>         draft-fett-oauth-dpop-04 is ineffective.
>
>
>     Denis
>
>     PS. The podcast is a nice effort but is far too long (29:37).
>>
>>     The mTLS vs DPoP was good in articulating how the two specs are
>>     alike, how they differ and which particular type of app they are
>>     meant to serve.
>>
>>     I'm saying this as a person who is generally allergic to
>>     technical podcasts :)
>>
>>     Maybe every RFC that comes out of this WG should have a podcast
>>     link at the top, where the authors discuss it in simple, honest
>>     and non-speccy terms, because that's often how people are best
>>     able to perceive the spirit and subtleties of some technical or
>>     spec work.
>>
>>     Vladimir
>>
>>     On 21/09/2020 09:40, Vittorio Bertocci wrote:
>>>
>>>     Dear all,
>>>
>>>     This is an informal mail to inform you that there’s a new
>>>     podcast <http://identityunlocked.com/>, identityunlocked.com
>>>     <http://identityunlocked.com/>, dedicated to inform and explain
>>>     new identity specs developments for developers.
>>>
>>>     You can find a more detailed explanation of the podcast’s goals
>>>     in
>>>     https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/,
>>>     but the TL;DR is that the spec themselves aren’t all that easy
>>>     to read for the non-initiated, and a lot of useful info emerges
>>>     during the discussions leading to the spec but rarely surface in
>>>     a usable form to the people who don’t participate in discussions.
>>>
>>>     The first episode
>>>     <https://auth0.com/blog/identity-unlocked-explained-episode-1/>,
>>>     featuring Brian Campbell discussing MTLS & DPoP, should give you
>>>     an idea of what season 1 of the show will look like.
>>>
>>>     The full list of the first run is available here
>>>     <https://auth0.com/blog/auth0-launches-identity-unlocked-the-identity-podcast-for-developers/>.
>>>     Of 6 episodes, 3 of them are about specifications coming out of
>>>     this WG- and all guests are actively involved in the IETF.
>>>
>>>     My main goals sharing this info here are
>>>
>>>       * *Letting you know that the podcast exists*, so that you can
>>>         make use of it if you so choose (e.g. referring people to it
>>>         if they need to better understand something covered in an
>>>         episode)
>>>       * *Soliciting proposals for new episodes*: topics you believe
>>>         are currently underserved, topics you are often asked about,
>>>         topics you would like to be interviewed about on the show
>>>       * *Growing the show’s subscriber base*. I was able to get
>>>         backing from my company to produce a podcast that has
>>>         exactly ZERO product pitches and is purely about identity
>>>         specs promotion, on the gamble that the topic does have an
>>>         audience finding it useful. So far the reception has been
>>>         great, and we need to keep it up if we want to have a season 2.
>>>
>>>     I hope you’ll find the initiative useful!
>>>
>>>     Cheers,
>>>
>>>     V.
>>>
>
>
> /CONFIDENTIALITY NOTICE: This email may contain confidential and 
> privileged material for the sole use of the intended recipient(s). Any 
> review, use, distribution or disclosure by others is strictly 
> prohibited.  If you have received this communication in error, please 
> notify the sender immediately by e-mail and delete the message and any 
> file attachments from your computer. Thank you./