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

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 18 May 2020 10:04 UTC

Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A8CCA3A0A67 for <oauth@ietfa.amsl.com>; Mon, 18 May 2020 03:04:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id IyFqXtAZcTgn for <oauth@ietfa.amsl.com>; Mon, 18 May 2020 03:04:30 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760973A0A64 for <oauth@ietf.org>; Mon, 18 May 2020 03:04:30 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id ACC2DF40753; Mon, 18 May 2020 03:04:26 -0700 (PDT)
To: n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com, naa@google.com, rdd@cert.org, kaduk@mit.edu, Hannes.Tschofenig@gmx.net, rifaat.s.ietf@gmail.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: dmitry.khlebnikov@rea-group.com, oauth@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20200518100426.ACC2DF40753@rfc-editor.org>
Date: Mon, 18 May 2020 03:04:26 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/VJMx9mcsTMb-iA7iKHl9xC6yNu8>
Subject: [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: Mon, 18 May 2020 10:04:33 -0000

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:

Type: Technical
Reported by: Dmitry Khlebnikov <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

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.

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