Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)

Benjamin Kaduk <kaduk@mit.edu> Tue, 02 June 2020 04:00 UTC

Return-Path: <kaduk@mit.edu>
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 703CF3A080C for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 21:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 FYNtUIv2OdJo for <oauth@ietfa.amsl.com>; Mon, 1 Jun 2020 21:00:35 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7547C3A080B for <oauth@ietf.org>; Mon, 1 Jun 2020 21:00:35 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05240Pkj006462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 2 Jun 2020 00:00:29 -0400
Date: Mon, 1 Jun 2020 21:00:25 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Dmitry Khlebnikov <dmitry.khlebnikov@rea-group.com>
Cc: Naveen Agarwal <na@ohauth.com>, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>, "n-sakimura@nri.co.jp" <n-sakimura@nri.co.jp>, oauth <oauth@ietf.org>, RFC Errata System <rfc-editor@rfc-editor.org>
Message-ID: <20200602040025.GJ58497@kduck.mit.edu>
References: <20200518100426.ACC2DF40753@rfc-editor.org> <20200523202532.GE58497@kduck.mit.edu> <CADNypP85O2uxAg05_dNn3Q0fHu5bqt093BkBVp_pRhyL5TOasA@mail.gmail.com> <CAKtfFtcEtvCBKDGtwqMO0W6Srx9Vw+g1XdaH3j8Ew-pOhZ9n3A@mail.gmail.com> <HK2PR01MB31869C68E3B28A3B32010B26BD8B0@HK2PR01MB3186.apcprd01.prod.exchangelabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <HK2PR01MB31869C68E3B28A3B32010B26BD8B0@HK2PR01MB3186.apcprd01.prod.exchangelabs.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5aJ-K8rV2sNkEgZXlAxzJxWdZD4>
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)
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: Tue, 02 Jun 2020 04:00:37 -0000

Hi Dmitry,

Thanks for clarifying the motivation.
I think it's shifted my stance a bit, to lean more towards classifying as
"editorial" (in that the protocol in the RFC itself is not affected) with
status of "Hold for document update".

-Ben

On Tue, Jun 02, 2020 at 12:32:48AM +0000, Dmitry Khlebnikov wrote:
> Naveen,
> 
> My concern with that section is that it provides misleading information about salting and that was the primary reason I was recommending to remove it.  However, knowing that we cannot amend what was already released as RFC (Unfortunately, somehow I missed the discussion in 2014 when I could have influenced that part), even if we make an errata saying that this part of the RFC is not applicable and one should not even think about applying a salt to a single unique hash the number of people confused and not being aware of the errata is going to be significant. Still, I think it is the right thing to do for those who are seeking for the information.
> 
> What prompted me to write it up (the request for errata) was that in a week I had several people approaching me in regard to this RFC and asking for advice (I am a Senior Security Adviser for one of Australia's largest realestate advertising platforms).  This coupled with the overall misunderstanding of salting (a techique against rainbow tables) and peppering (a technique to protect hashes from bruteforcing once the dataset is exfiltrated) of hashes pushed me to reach out.
> 
> --
> Dmitry Khlebnikov
> Senioe Security Adviser // REA Group
> +61 428 425291
> 
> ________________________________________
> From: Naveen Agarwal <na@ohauth.com>
> Sent: Tuesday, 2 June 2020 03:47
> To: Rifaat Shekh-Yusef
> Cc: Benjamin Kaduk; Dmitry Khlebnikov; n-sakimura@nri.co.jp; oauth; RFC Errata System
> Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC7636 (6179)
> 
> [External Email]
> 
> 
> As one of the author, writing from my persona email.
> 
> I think at the time someone must have suggested that we should add a salt for the code_verifier before hashing and this was added to explain that there is no need to do that. As Dmitry agreed that salting is not really applicable in this case and I agree that  the section could have been written in a better way. But I do think when people try to implement they may ask the same question as they have been told again and again that you should salt your hashes. So leaving it in place doesn't hurt (as it is not making any bad recommendation but not doing a great job justifying why we didn't add salting).
> 
> Thanks
> 
> Naveen
> 
> On Sun, May 31, 2020 at 12:41 PM Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com<mailto:rifaat.s.ietf@gmail.com>> wrote:
> Nat, John,
> 
> Do you guys have any thoughts on this errata?
> 
> Regards,
>  Rifaat
> 
> 
> On Sat, May 23, 2020 at 4:25 PM Benjamin Kaduk <kaduk@mit.edu<mailto:kaduk@mit.edu>> wrote:
> Authors, WG, any comments?
> 
> Right now the likely dispositions seem to me to be Editorial/HFDU or
> Rejected; the text is noting that salting is not used and attempting to
> give an explanation of why that's the right choice.  It's not clear that
> the WG was in error to include some such discussion at the time of
> publication, which is essentially what this errata report is claiming.
> 
> Thanks,
> 
> Ben
> 
> On Mon, May 18, 2020 at 03:04:26AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7636,
> > "Proof Key for Code Exchange by OAuth Public Clients".
> >
> > --------------------------------------
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid6179
> >
> > --------------------------------------
> > Type: Technical
> > Reported by: Dmitry Khlebnikov <dmitry.khlebnikov@rea-group.com<mailto:dmitry.khlebnikov@rea-group.com>>
> >
> > Section: 7.3
> >
> > Original Text
> > -------------
> > 7.3.  Salting the code_challenge
> >
> >    To reduce implementation complexity, salting is not used in the
> >    production of the code challenge, as the code verifier contains
> >    sufficient entropy to prevent brute-force attacks.  Concatenating a
> >    publicly known value to a code verifier (containing 256 bits of
> >    entropy) and then hashing it with SHA256 to produce a code challenge
> >    would not increase the number of attempts necessary to brute force a
> >    valid value for code verifier.
> >
> >    While the "S256" transformation is like hashing a password, there are
> >    important differences.  Passwords tend to be relatively low-entropy
> >    words that can be hashed offline and the hash looked up in a
> >    dictionary.  By concatenating a unique though public value to each
> >    password prior to hashing, the dictionary space that an attacker
> >    needs to search is greatly expanded.
> >
> >    Modern graphics processors now allow attackers to calculate hashes in
> >    real time faster than they could be looked up from a disk..  This
> >    eliminates the value of the salt in increasing the complexity of a
> >    brute-force attack for even low-entropy passwords.
> >
> > Corrected Text
> > --------------
> >
> >
> > Notes
> > -----
> > The section misrepresents the information about "salting" and the whole idea
> > of "salting" is not applicable to a standalone hash.  I suggest to drop the entire
> > section as irrelevant to the rest of the standard.
> >
> > For some reason the section implies that "salting" is protecting and increasing
> > entropy of a single hash, which is not what "salting" is about and is not the
> > reason for the technique.  The section is also making a speculative assumptions
> > about the low-entropy tendency in password hashes and makes an incorrect
> > conclusion on the benefits of "salting" for a password hash.
> >
> > One could argue that the entropy and the complexity required to bruteforce a hash
> > and a salted hash for the same password (where the same hashing algorithm is
> > applied) are approximately the same in most cases (or just slightly more
> > complex for the salted version if the producer of the hash used a non-standard
> > routine in relation of mixing in the salt, e.g. instead of appending the salt
> > it inserts in in the middle of the password to be hashed).  In any case, that
> > public data is already known to the attacker and it is just a matter of the
> > configuration for the bruteforcing tool (such as JohnTheRipper) to incorporate
> > the knowledge.
> >
> > Just as an illustration: consider an example password ('abc'), an example salt
> > ('123'), and that the hash is generated using a concatinated version of these
> > two (e.g. HASH('abc123')).  Since the salt is included with the hash in plain
> > text, the bruteforcer would just need to set their tool up with the "^.*123$"
> > pattern making the salt essentially a string terminator which is not affecting
> > the bruteforce effort in any way).
> >
> > More and more people I meet are confused about the problem area the "salting"
> > technique was invented to address: it is to increase the entropy of a set of
> > passwords, so the same password would not result in the same hash value, with
> > the primary goal is to prevent attackers to be able to re-use pre-calculated
> > hashes (e.g. rainbow hash tables) or, in the early stages of the attack, to
> > make it impossible to quickly assess what hashes the attacker should focus on
> > (e.g.  when you have 1000 hashes and without salts you can easily spot that
> > some hashes are the same, which means breaking these one would gain much more
> > in comparison to unique hashes in the same set).
> >
> > This being said, I am suggesting to drop section 7.3 completely as irrelevant,
> > since what we currently have is very confusing and seeds unnecessary and
> > wrong ideas that "salting" can improve the security of a single hash by itself.
> >
> > Instructions:
> > -------------
> > This erratum is currently posted as "Reported". If necessary, please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > can log in to change the status and edit the report, if necessary.
> >
> > --------------------------------------
> > RFC7636 (draft-ietf-oauth-spop-15)
> > --------------------------------------
> > Title               : Proof Key for Code Exchange by OAuth Public Clients
> > Publication Date    : September 2015
> > Author(s)           : N. Sakimura, Ed., J. Bradley, N. Agarwal
> > Category            : PROPOSED STANDARD
> > Source              : Web Authorization Protocol
> > Area                : Security
> > Stream              : IETF
> > Verifying Party     : IESG
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org<mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth