Hi Denis, On Fri, May 01, 2020 at 10:47:18AM +0200, Denis wrote: > Comments on draft-ietf-oauth-dpop-00. > > 1) In section 9 (Security considerations), the text states: > > DPoP does not, however, achieve the > same level of protection as TLS-based methods such as OAuth Mutual > TLS [RFC8705] or OAuth Token Binding [I-D.ietf-oauth-token-binding] > (see also Section 9.1 and Section 9.4). > > draft-ietf-oauth-token-binding-08 [i.e. I-D.ietf-oauth-token-binding] > expired on April 22, 2019, > thus it does not seem adequate to refer to it.
It can still be useful to refer to technology that ended up not getting deployed, for comparison against the work in questionn. > 2) The text states: > > 9.1. DPoP Proof Replay > > If an adversary is able to get hold of a DPoP proof JWT, the > adversary could replay that token at the same endpoint (the HTTP > endpoint and method are enforced via the respective claims in the > JWTs). > > This is true, but there is a worse case: if a client legitimately obtains > a DPoP proof JWT and collaborates > with another client, then it can provide it to that other client. Would we not consider one or both such clients to be "an adversary" in that situation? They are, after all, behaving contrary to the expected flow. > 3) The text states: > > 9.4. Message Integrity > > DPoP does not ensure the integrity of the payload or headers of > requests. The signature of DPoP proofs only contains the HTTP URI > and method, but not, for example, the message body or other request > headers. > > This is an intentional design decision to keep DPoP simple to use, > but as described, makes DPoP potentially susceptible to replay > attacks where an attacker is able to modify message contents and > headers. In many setups, the message integrity and confidentiality > provided by TLS is sufficient to provide a good level of protection. > > DPoP alone or DPoP used in conjunction with TLS does not provide any > protection in case of collusion attacks > between collaborative clients. Do you think that the reader would expect such protection in the absence of text in the security considerations section? My personal expectation is that the reader would not expect protection against a client that colludes with some other (malicious) party, and that such a client would itself be deemed malicious. Thanks, Ben > Collaborative attacks between clients cannot be countered using > software-only implementations. > It should also be noticed that the use of secure elements to only protect > private keys is insufficient, > since a collaborative client can still perform all the cryptographic > computations needed by the other client. > > These considerations about collaborative clients should be added into the > security considerations section. > > Denis _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
