Ok, I look forward to your enumerating all of the things the application will have to check, AND demonstrating that those checks are simpler than just using a different syntax than JWS.
On Thu, Aug 1, 2013 at 2:37 PM, Mike Jones <[email protected]>wrote: > The implementation is supposed to implement whatever algorithms it > does. The **application** decides which of those algorithms meet its > security requirements. That’s always been true. That’s hardly complexity > – it’s normal security architecture.**** > > ** ** > > Just because my library implements MD2, that doesn’t mean that my > application should accept objects using it. The same applies to “none” and > “rot13”.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* Richard Barnes [mailto:[email protected]] > *Sent:* Thursday, August 01, 2013 5:31 AM > > *To:* Mike Jones > *Cc:* Matt Miller (mamille2); jose issue tracker; < > [email protected]>; <[email protected]> > *Subject:* Re: [jose] #36: Algorithm "none" should be removed**** > > ** ** > > 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
