If "none" is going to be an allowed value, then presumably someone is going to implement it. For instance, a JWT implementation.
What is that poor implementation supposed to do? When an attacker changes the "alg" value to "none", the modified object passes the support check, so the implementation pulls the right key for the "kid" value, and happily validates. Now I expect your argument is going to be "We provide keys out of band, so if the implementation has gotten a key with "alg":"none", then there's an error." Or, "We only allow "alg":"none" over specific secure channels." These responses demonstrate that you require application-layer assumptions in order for "alg":"none" to be secure. And that means that (1) in the spec, you need to enumerate all of those assumptions, and (2) any implementation that supports "alg":"none" has to verify that those assumptions are true. And that latter thing will be impossible for a general JOSE stack. Are you really willing to embrace all that complexity to avoid a difference of a single dot? On Thu, Aug 1, 2013 at 2:23 PM, Mike Jones <[email protected]>wrote: > You already have to have code to verify that the “alg” value used is one > that your application accepts. You’ll already reject it if it’s not in > your supported algorithm set. If your application doesn’t want to accept > “alg”:”none” the same code path that would reject “alg”:”rot13” would > reject “alg”:”none”.**** > > ** ** > > I’m not making your code more complicated. I’m sure that you already have > the code to reject algorithms your application doesn’t support.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, August 01, 2013 5:20 AM > *To:* Mike Jones > *Cc:* Matt Miller (mamille2); jose issue tracker; < > [email protected]>; <[email protected]> > > *Subject:* Re: [jose] #36: Algorithm "none" should be removed**** > > ** ** > > Sure it requires special parsing. You have to have special checking when > there's "alg":"none" to make sure there's no "kid" or "x5c", or anything > else that would hint at a downgrade attack. It's far more complicated than: > **** > > ** ** > > switch (token.split(".").length) {**** > > case 2: process_unsigned(token); break;**** > > case 3: process_signed(token); break; > case 5: process_encrypted(token); break;**** > > default: throw new MalformedTokenError();**** > > }**** > > ** ** > > Why are you always trying to make my code more complicated, Mike? :)**** > > ** ** > > I have sent a mail to the OAuth list suggesting a revision to the JWT spec. > **** > > ** ** > > --Richard**** > > ** ** > > On Thu, Aug 1, 2013 at 2:11 PM, Mike Jones <[email protected]> > wrote:**** > > That would require special parsing. “alg”:”none” doesn’t.**** > > **** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, August 01, 2013 5:03 AM > *To:* Matt Miller (mamille2) > *Cc:* jose issue tracker; < > [email protected]>; Mike Jones; < > [email protected]> > *Subject:* Re: [jose] #36: Algorithm "none" should be removed**** > > **** > > If you really want to have a header, you could also have the unsigned JWT > have 2 components (1 dot). That way, you would demux > unsigned/signed/encrypted based on number of dots, not "alg".**** > > **** > > --Richard**** > > **** > > On Thu, Aug 1, 2013 at 1:51 PM, Matt Miller (mamille2) <[email protected]> > wrote:**** > > If something doesn't have a signature (or MAC, yeah yeah yeah), then I > have a really hard time calling it a JWS (JSON Web Signature), and there > fore have a really hard time seeing "alg":"none" as useful. > > Assuming this is using compact serialization: Why not just send in the > base64url(payload)? Then you can tell if you have an actually signed JWT > (3 dots) versus an unsigned JWT (0 dots). > > > - m&m > > Matt Miller < [email protected] > > Cisco Systems, Inc.**** > > > On Aug 1, 2013, at 1:23 PM, jose issue tracker < > [email protected]> wrote: > > > #36: Algorithm "none" should be removed > > > > > > Comment (by [email protected]): > > > > And sure enough, working groups across the IETF are having to explicitly > > forbid the use of null ciphersuites. They provide empirical evidence > that > > this design pattern is a bad idea. > > > > As I've pointed out before, you can add that verification algorithm, but > > you will not have a good time writing security considerations around it. > > Checking that you support "none" is not enough -- you have to check that > > *nothing* *else* in the header could possibly indicate that a different > > signature algorithm should be used. > > > > So we have something that (1) causes a lot of spec work, (2) causes > > security vulnerabilities under likely implementaiton designs, and (3) has > > no use case, and (4) will haunt us for years to come (how many times do > > you want to write 'MUST NOT use "alg":"none"'?). Sounds like a recipe > for > > success! > > > > -- > > > -------------------------+------------------------------------------------- > > Reporter: | Owner: draft-ietf-jose-json-web- > > [email protected] | [email protected] > > Type: defect | Status: new > > Priority: major | Milestone: > > Component: json-web- | Version: > > signature | Resolution: > > Severity: - | > > Keywords: | > > > -------------------------+------------------------------------------------- > > > > Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/36#comment:4 > > > > jose <http://tools.ietf.org/jose/> > >**** > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
