The one thing I'm not super comfortable about here is my PASETO take. My attitude going in was that PASETO has a lot of boosters and not a lot of critical takes. I can beat up on Macaroons because we're using them, and I'm going to follow up with a post about what our Macaroons like like. I'm not doing that with PASETO. So, like, I stand by it, but take it for what it's worth.
Later
I turned the post into a handy chart. Let me know if you want a poster of it.
In your article, you say "For reasons I will never understand, the PASETO authors submitted it to CFRG for consideration. Never do this". Is issue here the implied design-by-committee that led to JWT being a bad standard, or something else? It does seem like it found some valid issues in PASETO, at least, so I had trouble understanding your point.
CFRG's response to PASETO was tepid. The few people who participated in the thread identified three issues:
* The v1 local tokens used a novel nonce construction (I'm doing this from memory) and CFRG's take was "standard constructions or GTFO".
* The HMAC/RSA thing, which PASETO noted and documented but didn't fix.
* The fact that PASETO is basically a restricted profile of JWTs, begging the question of why it didn't just specify a restricted JWT profile.
I don't think this feedback was especially valuable.
I think there are subjects on which CFRG discussions shed a fair bit of light, when they're high-profile enough to drag academic cryptographers into the fray. But the other thing that happens in CFRG is that bad stuff (like the Dragonfly PAKE) gets blessed (because there's no outcome besides "this is fine" and "this is trivially broken" --- and even "this is trivially broken" can get laundered back to "this is fine" if the threads get tedious enough).
In the worst case, you get people proposing bikeshed changes to constructions that are already de facto standards, which (if I remember right) happened with Curve25519, though thankfully not successfully.
I think the whole practice of standards based cryptography is mostly discredited at this point. Signal Protocol isn't a standard despite being the reference model for most secure messaging systems. WireGuard isn't a standard either. The original ethos of the IETF was that things get popular, and then they get standardized. IETF does a lot of stuff de novo now, which is how we end up with stuff like Heartbleed and JWT.
I have no idea if I am reading the chart right, but it looks like biscuits are the worst for scalability. Why is that?
I would imagine that if the entire policy is encoded in the biscuit, it is very easy to evaluate without needing to call external services. And it can be extended like macaroons without needing a central authority, assuming I groked your blog post correctly. The only issue I can see is revocation.
Ok so first of all let me just say the chart was a joke I wrote for Twitter. Then Joël Franusic suggested I add a bunch of meta tags to the post so that Twitter would show the chart as the "card" for the post on Twitter. To make that work I had to pull the chart into the actual site (I'd just posted it to Twitter originally), so I figured, what the hell, might as well slap it on the end of the post. I don't even know if the ratings I came up with make sense! I docked Biscuits because they're chained public key verification on an per-API-request basis, but who knows? I haven't used them! The chart isn't serious! And I feel like it's all I'm talking about now!
To top it all off, my dumb meta tags didn't even work; they needed to be in the <head> of the page, and I'll be damned if I'm going to figure out how to do that in our static site generator configuration.
I just wanted the Carl Yastrzemski with the big sideburns.
Later
I turned the post into a handy chart. Let me know if you want a poster of it.
https://twitter.com/tqbf/status/1430303808945524739