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.) _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
