3 ms·

Specifying "v1" "v2" or "v3" is not materially different than specifying the exact algorithm by name, which is what JWT does. You (and the linked article) are

Specifying "v1" "v2" or "v3" is not materially different than specifying the exact algorithm by name, which is what JWT does. You (and the linked article) are selectively quoting the JWS specification too, to imply that the server needs to always handle a token presented to it, regardless of the specified algorithm; the article is misleading the reader by doing so. The RFC also states, > Even if a JWS can be successfully validated, unless the algorithm(s) used in the JWS are acceptable to the application, it SHOULD consider the JWS to be invalid. As for the section about "MUST be understood and processed": the standard is simply saying that implementors must use the "alg" field. You can't ignore it. Extending that to "must process anything the client sends" results in nonsense. The suggestion to "use NaCl" ignores the entirety of JWT claims, and foists implementation of that functionality onto every single consumer that needs them. (And you hope that they recognize that they need them.) Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. While some JWT implementations had bugs in the past, these same bugs could easily be present in the custom implementations of your proposal, of which there would be many.

CiPHPerCoder 10y ago
From https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 > * Flaws in crypto protocols aren't exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and "cipher suite" negotiation towards other mechanisms. Trevor Perrin's Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That's a disqualifying own-goal. My proposal replaces the joinery with "select a version". You don't get to mix-and-match primitives. You won't fall into the trap of Reasoning By Lego. > Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. I'm not throwing my hands up and saying "fend for yourselves". I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time, as keeping a roof over my family's head takes precedence over doing a lot of thankless unpaid work.
- deathanatos 10y ago
  This is a much better point (or perhaps a much better way of stating it) than what I got from your original post. I agree wholehearted that you don't want to give the end-user mix-and-match primitives. But I don't think that JWT really gives you that, at least at the level I think you're discussing. For example, JWT doesn't let you choose an asymmetric cipher and a hash algorithm; you have to choose a precomposed whole, such as "RS256" (RSA w/ SHA-256) or "HS256" (HMAC w/ SHA-256). To me, this seems equivalent to NaCl, in a sense. In JWT, I must choose one of "RS256", "HS256", etc. In NaCl, I must choose one of the crypto_* functions. Are these not both giving the user equivalent choices between equivalently pre-composed functionality? (Are you simply saying that the JWT standards offer too many choices between essentially equivalent cryptographic combinations, such as multiple choices for HMAC or RSA, and/or that you disagree w/ the exact combinations offered?) > I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time Perhaps it's what you're leaving unsaid, but the gist I get from your proposal is that you're discarding the entirety of JWT's claims section, essentially equating a JWT with an authenticated and potentially encrypted message; i.e., the output of the NaCl functions that you present.
tptacek 10y ago
You're missing the distinction between algorithms, which rarely have flaws, and protocol constructions, which often do. Algorithm negotiation within an otherwise static protocol incurs complexity, which has a security cost. Just as importantly, it doesn't address the real origin of cryptographic protocol flaws. Note how, in order to correct cryptographic flaws in TLS, we had to push people first from SSL3 to TLS 1.0, and then later to TLS 1.1.
- deathanatos 10y ago
  Certainly it does, but what would you suggest JWT do differently? One can't realistically hard-code the algorithm(s) in use: that would prevent any ability down the road to upgrade to a better set.
  - tptacek 10y ago
    Once again: 1. "Hard-code" the simplest possible sound crypto construction that solves the specific problem the protocol is meant to solve. 2. Put a version on the whole protocol. 3. If the crypto constructions later need to be amended, upgrade the whole protocol. The anti-pattern is attempt to use a static "outer protocol" with a negotiated and regularly changing "inner protocol" --- that's an architecture we know from experience does not work well. You know you're in trouble when developers are forced or even encouraged to make decisions between things like RSA and ECC.

CiPHPerCoder 10y ago

From https://news.ycombinator.com/item?id=14292223 https://news.ycombinator.com/item?id=14292223 > * Flaws in crypto protocols aren't exclusive to, but tend to occur mostly in, the joinery of the protocol. So crypto protocol designers are moving away from algorithm and "cipher suite" negotiation towards other mechanisms. Trevor Perrin's Noise framework is a great example: rather than negotiating, it defines a family of protocols and applications can adopt one or the other without committing themselves to supporting different ones dynamically. Not only does JWT do a form of negotiation, but it actually allows implementations to negotiate NO cryptography. That's a disqualifying own-goal. My proposal replaces the joinery with "select a version". You don't get to mix-and-match primitives. You won't fall into the trap of Reasoning By Lego. > Centralizing implementations of cryptographic code into a few, well-vetted implementations is better than just throwing our hands up and telling the community to fend for themselves. I'm not throwing my hands up and saying "fend for yourselves". I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time, as keeping a roof over my family's head takes precedence over doing a lot of thankless unpaid work.

deathanatos 10y ago
This is a much better point (or perhaps a much better way of stating it) than what I got from your original post. I agree wholehearted that you don't want to give the end-user mix-and-match primitives. But I don't think that JWT really gives you that, at least at the level I think you're discussing. For example, JWT doesn't let you choose an asymmetric cipher and a hash algorithm; you have to choose a precomposed whole, such as "RS256" (RSA w/ SHA-256) or "HS256" (HMAC w/ SHA-256). To me, this seems equivalent to NaCl, in a sense. In JWT, I must choose one of "RS256", "HS256", etc. In NaCl, I must choose one of the crypto_* functions. Are these not both giving the user equivalent choices between equivalently pre-composed functionality? (Are you simply saying that the JWT standards offer too many choices between essentially equivalent cryptographic combinations, such as multiple choices for HMAC or RSA, and/or that you disagree w/ the exact combinations offered?) > I've outlined what needs to be changed to make it secure, and said I'll write a formal spec when I have the time Perhaps it's what you're leaving unsaid, but the gist I get from your proposal is that you're discarding the entirety of JWT's claims section, essentially equating a JWT with an authenticated and potentially encrypted message; i.e., the output of the NaCl functions that you present.

tptacek 10y ago

You're missing the distinction between algorithms, which rarely have flaws, and protocol constructions, which often do. Algorithm negotiation within an otherwise static protocol incurs complexity, which has a security cost. Just as importantly, it doesn't address the real origin of cryptographic protocol flaws. Note how, in order to correct cryptographic flaws in TLS, we had to push people first from SSL3 to TLS 1.0, and then later to TLS 1.1.

deathanatos 10y ago
Certainly it does, but what would you suggest JWT do differently? One can't realistically hard-code the algorithm(s) in use: that would prevent any ability down the road to upgrade to a better set.
- tptacek 10y ago
  Once again: 1. "Hard-code" the simplest possible sound crypto construction that solves the specific problem the protocol is meant to solve. 2. Put a version on the whole protocol. 3. If the crypto constructions later need to be amended, upgrade the whole protocol. The anti-pattern is attempt to use a static "outer protocol" with a negotiated and regularly changing "inner protocol" --- that's an architecture we know from experience does not work well. You know you're in trouble when developers are forced or even encouraged to make decisions between things like RSA and ECC.