httpdir review notes

[aaronpk]

Summarized action items based on httpdir review:

https://mailarchive.ietf.org/arch/msg/oauth/RZty9PDLAVNMyfvDoOeGCWG3TGE/

• clarify threat model up front (suggestion in email)
• clarify "client" is the application in 6.3.3.2 (the "identity" term is throwing this off)
• Section 6.3.4.2.1 clarify how refresh token isolation helps
• Find an alternative to "perfectly secure storage mechanism"
• make DPoP guidance more prominent (Section 6.3.4.2.2)
• Section 6.3.4.2.3: Clarify why there is no distinguishing between refresh tokens and access tokens
• Section 7.4.1.1: Clarify why this is relevant to the authorization code + PKCE flow, not just implicit
• Section 8.3: TBD, see email
• Section 8.5: Mention sync downside of LocalStorage to deemphasize it further
• Section 8.6: Change "ultimately store data in plain text" to "cannot rely on encryption at rest"
• Expand on protections that CSP can provide
• cite first uses of PKCE, DPoP, etc
• fix references to "section X of Y" markup
• Find stable reference to webstorage

[aaronpk]

@philippederyck I'd appreciate your thoughts on the point about CSP. Do you think it's worth adding a new section to the security considerations describing CSP and how it can help? If you have any other suggestions for the remaining points in this list I would be happy to get your feedback.

[philippederyck]

Mentioning CSP without going into details was a deliberate choice at the time. The CSP spec itself states the following:

CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth.

Adding more details of what CSP can or cannot do requires a lot of nuance, such as discussing potential CSP bypasses, the use of hashes, nonces, and 'strict-dynamic'. E.g., if your CSP's script-src approves a CDN hosting a AngularJS 1.x library, or a JSONP endpoint, your CSP can be trivially bypassed. This ebook I have written a while ago gives you a good idea of what goes into handling all of this.

Additionally, CSP works as a defense against XSS, but not against other attacks. For example, if your application contains third party code (E.g., <script src="https://example.com/chatbot.js">) and that third-party code is compromised, the attacker also gains control over the application. In such cases, CSP is unlikely to stop this attack (unless you use remote hashes in combination with Subresource Integrity).

Concretely, I believe CSP is absolutely useful as a second line of defense, but I don't think this spec is the place to discuss the details of CSP.

With all this context, I also think it is important to note that the use of CSP does not change the security recommendations or threat analysis sections of the spec. CSP will make it harder for malicious JS to gain a foothold, but when it happens, none of that matters anymore.

I do think it would be useful to mention CSP higher up in the spec (e.g., in the intro of section 5)

[aaronpk]

Thanks, I agree with all that, it seems like what you wrote here would be sufficient as a CSP section in the security considerations, what do you think?

[philippederyck]

I have added a paragraph with a list of defenses that should be applied, giving proper context and including CSP. I think this is more useful that expanding on CSP