[OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-spop-12: (with COMMENT)

["Ben Campbell" <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-oauth-spop-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-spop/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I share Barry's and Alexey's concerns about both allowing "plain" and
defaulting to it.  I have some other comments, which may overlap with the
comments from others:

Substantive:

-- section 1, pre-condition 3: "All OAuth 2.0 native app client-instances
use the same client_id.  Secrets provisioned in client binary
applications cannot be considered confidential."

Is that part of the pre-condition per-se, or a general statement? If the
former, wouldn't a potential mitigation for this attack be to ensure the
precondition doesn't occur?

-- section 1, paragraph after precondition list: "not applicable since
they rely on a per-client instance secret or aper client instance
   redirect URI."

I infer that these are not realistic? If so, it might be useful to say
why. For instance, would one way to mitigate this attack be to make sure
you have per-client secrets and redirect URIs?

-- 4.4.1, last sentence:

Does this advice change if people register new challenge methods?  That
is, what if the client supports "plain", and "foo" but not S256, where
foo is more secure than plain. Can it still use "plain"?

-- 6.2:

Does the ability to register new challenge methods introduce bid-down
attacks? (Assuming that any such method is more secure than "plain", and
that the server might not support it.)

Also, I share Barry's concern that the registration procedures require
quite a bit of special treatment from IANA.

-- 7.4:

This seems to need a normative reference to 6819.

-- 7.5: How does the guidance in section 10.8 of 6479 apply to the
code_verifier? Also, I think the last sentence requires this draft (or
some other) to update 6749.

Editorial:

-- 4.4, 2nd to last paragraph: "The server MUST NOT include the
"code_challenge" value in client requests in a form that other entities
can extract."

should "client requests" be "responses to clients"? (I assume the server
does not send client requests--or do I have the terminology wrong?)

-- 4.4.1, first paragraph:
Please expand PKCE on first mention. (It might help to declare PKCE in
the introduction.)