Re: [OAUTH-WG] draft-ietf-oauth-spop-10

John Bradley <> Wed, 18 February 2015 04:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 970B41A899C for <>; Tue, 17 Feb 2015 20:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JIouEYQqoYNm for <>; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B35541A898F for <>; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
Received: by padet14 with SMTP id et14so11660256pad.11 for <>; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=WhlvG8g0PH7cfETLCgp03P+yVrBDSd8/kWewAeKFBPk=; b=mXgOqwbLv5EY9wKlmacIbQy3VM0iRSap0Ubxw4l/kv2en044DcpAhKRiKxdp+lWU1H 2hIkX1XSWwB3/bd73I3GMBBD6itPkO2Xz7MgrmHemuqTZ6a2CYMlz5q71sYDb4jvHpLq Bh5AXpLW6nSJyRGgsqg9CF/6mwz9kmmK30dF2jhckLqATMMzl3OZYCvxEtlfpRRiL3aH GxsfRpxUAvzPxCErqHkgLNJeedYfec08ljVqQxYCIVEG+MW5k0b6Vgt8XfPWrWOIAa1W SniWKLcmX49uktdZTy6sHFeQrS8Dr7IhFCGnfC55oRGLB4AA5qZK9AkuxIgzi+QrvtY3 UIVw==
X-Gm-Message-State: ALoCoQm9p9an3X1eB0WWvlmKBrgeuR5VgPFBDFbhxgrtghbXxJ3BRD32X9/tE3xHMSqGhX0fz/jw
X-Received: by with SMTP id ra7mr36922906pbc.140.1424234529292; Tue, 17 Feb 2015 20:42:09 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id sf7sm19141860pbc.29.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Feb 2015 20:42:08 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_D30D56C1-4ED2-4B62-A956-3374BE20C531"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <>
In-Reply-To: <>
Date: Tue, 17 Feb 2015 20:42:06 -0800
Message-Id: <>
References: <>
To: Hannes Tschofenig <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc: "" <>, Naveen Agarwal <>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-spop-10
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Feb 2015 04:42:12 -0000

We have discussed on the list making allowing the entropy for plain to be smaller.

32bytes was selected as a good value for S256.  

The reason for S256 vs plain is that you are assuming an attacker is going to intercept the request, and thus you want to have enough entropy to prevent offline brute force.

For plain you are assuming that the attacker can't intercept the request, and if they do more entropy won't help you.

In the plain case you are only protecting against a on line guess for a single use token.   That could safely be much lower entropy as it is not protecting against off-line brute force.
128bits would be more than enough in that case.   I left it as 256bits for both to not introduce more options and not confuse people about why plain needs less entropy than S256.

What is the WG feeling should we recommend different minimum values for each of the transforms?

John B.

> On Feb 17, 2015, at 8:56 AM, Hannes Tschofenig <> wrote:
> Hi Nat, John, Naveen,
> thanks a lot for your work on the document.
> I still need responses to this mail to complete the shepherd writeup:
> I definitely need the IPR confirmation.
> It would also be helpful to have someone who implemented the
> specification as it currently is. I asked Brian and Thorsten for
> clarification regarding their statements that they implemented earlier
> versions of the spec.
> As a final remark I still believe that the text regarding the randomness
> is still a bit inconsistent. Here are two examples:
> 1) In the Security Consideration you write that "The security model
> relies on the fact that the code verifier is not learned or guessed by
> the attacker.  It is vitally important to adhere to this principle. "
> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD have
> enough entropy to make it impractical to guess the value.  It is
> RECOMMENDED that the output of a suitable random number generator be
> used to create a 32-octet sequence."
> There is clearly a long way from a SHOULD have enough entropy to the
> text in the security consideration section where you ask for 32 bytes
> entropy.
> It is also not clear why you ask for 32 bytes of entropy in particular.
> Ciao
> Hannes