This is an excellent point that will be rectified in the documentation and future drafts of the RFC.
How is this better than JOSE? It's better in that it's a first draft, not a final specification. :P Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com> On Mon, Apr 23, 2018 at 12:43 PM, Neil Madden <[email protected]> wrote: > > > On 23 Apr 2018, at 14:44, David Adrian <[email protected]> wrote: > > > > > If we have to invent a new standard each time an existing standard is > implemented with a security flaw, we have a lot of work to do. > > > > You fundamentally cannot fix a standard with unusable to the point of > broken negotiation by extending the negotiation. If you don't want PASETO > to be a new standard, call it JOSEv3. > > I don’t believe that PASETO is actually fundamentally different from JOSE > in this respect. Is there a meaningful distinction between v1.local.<token> > and {“alg”:”v1.local”}.<token> ? > > One of the critical vulnerabilities historically in JOSE implementations > was [1], whereby if an implementation was using RSA signed JWTs an attacker > could get the server’s public key and use it as if it was a HMAC key to > produce a forged JWT with {“alg”:”HS256”} in the header. If the JWT library > just provided a verify(String jwt, Key key) function then it might be > tricked into using the attacker’s choice of algorithm (HS256) with the > server’s RSA public key and the JWT would validate. Oops! > > This flaw has been rightly criticised, including by the authors of PASETO.. > Don’t let the attacker chose the algorithm! > > But wait, aren’t PASETO implementations potentially vulnerable to *exactly > the same vulnerability*?! If my server is set up to use v2.public (Ed25519) > signed PASETO tokens, what is to stop an attacker grabbing my Ed25519 > public key (which is a 32 byte value) and using it to create a PASETO token > using v2.local? Recall that v2.local takes a 32 byte symmetric key. If the > PASETO library just has a function verify(String paseto, Key key) and looks > at the header to decide how to process the token, then it will have exactly > the same vulnerability that those JOSE libraries had. So how does PASETO > the spec make this vulnerability less likely? > > Looking at the reference implementation [2], it seems that if the library > user didn’t set an allowed purpose then the only thing stopping this is a > type check on the public key class. In other words, the implementor took > extra safe-guards beyond those documented in the specification. Phew! > > Am I missing something here? As far as I can tell, the PASETO docs and > draft RFC don’t even mention this as a consideration. How is this better > than JOSE? > > [1] https://auth0.com/blog/critical-vulnerabilities-in- > json-web-token-libraries/ > [2] https://github.com/paragonie/paseto/blob/master/src/Parser.php#L159 > > Neil > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
