What happens when I give you a new alg parameter value because I have defined a new algorithm?
From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Monday, August 19, 2013 1:31 PM To: Phil Hunt Cc: Richard Barnes; jose issue tracker; [email protected]; John Bradley; Justin Richer; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed Because it breaks the invariant that you use the "alg" parameter value to determine how to process the JOSE object. From: Phil Hunt [mailto:[email protected]] Sent: Monday, August 19, 2013 1:29 PM To: Mike Jones Cc: Richard Barnes; John Bradley; jose issue tracker; Justin Richer; [email protected]; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed I think it is dangerous to say signature is valid if alg:none. Richard is right. The app will get a binary response and will assume there was a signature. Why not simply detect if "alg":"somealg" is present and if not, proceed direct to payload processing? Phil @independentid www.independentid.com [email protected] On 2013-08-19, at 1:23 PM, Mike Jones <[email protected]> wrote: It is accepted. That doesn't mean that the application should accept it unless it validates that the actual algorithm used meets its security requirements, whether it's "none", or not. (For instance, if you require HS512 or ES512, your application will need to reject inputs that used HS256, etc.) This is a basic requirement for secure applications - not a new requirement created by the presence of "none". -- Mike From: Richard Barnes [mailto:[email protected]] Sent: Monday, August 19, 2013 1:21 PM To: Mike Jones Cc: John Bradley; Justin Richer; jose issue tracker; [email protected]; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed But that signature is valid for that algorithm. So a generic JWS parser will show it as accepted. On Mon, Aug 19, 2013 at 4:18 PM, Mike Jones < <mailto:[email protected]> [email protected]> wrote: Having an empty signature segment already makes it recognizably different. From: Richard Barnes [mailto: <mailto:[email protected]> [email protected]] Sent: Monday, August 19, 2013 1:18 PM To: John Bradley Cc: Justin Richer; jose issue tracker; Mike Jones; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed On Mon, Aug 19, 2013 at 3:48 PM, John Bradley < <mailto:[email protected]> [email protected]> wrote: In OAuth and Connect there are cases where you are receiving tokens from multiple sources. By allowing none as a alg option we can process signed or unsigned tokens with the same basic handler by inspecting the first segment. I note currently that while none has three segments the last segment must be empty. I think that is sufficient to keep people from becoming confused. Making it two segments will break existing parsers for no good reason. No, there's a very good reason. Something that is not signed should not be accepted as a JSON Web Signature object. Acceptance of a JWS implies that the payload and protected headers were integrity protected from the signer; that is not true for "alg":"none". Also, it's not clear that this change will break existing parsers. For example, the NimbusDS parser would successfully parse a two-segment object as a "plain JWT" < <https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583 dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master> https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/ca58ff0ece35243aa6546583d ffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master> What we call it I am flexible about, if it is a unsigned JOSE object in compact serialization i am fine. I would also be completely fine with an unsigned "header + content" structure (though I don't think it adds any value). But it must be recognizably different from JWS. --Richard, who is honestly kind of floored that there's all this argument over a single "." character John B. On 2013-08-19, at 12:30 PM, Justin Richer < <mailto:[email protected]> [email protected]> wrote: > I don't normally jump into the discussion on this list, but I've been using the output of JOSE for quite some time now and am a committer on the NimbusDS JOSE JWT library. However, with tonight's call coming up (which I won't be able to make) I wanted to jump in and say that from my perspective, alg:none makes a lot of sense. There's a need for being able to send unsigned content with JOSE objects, and that's been pretty well established by others on the list here. As an implementor, though, I think it makes the most sense to have the unsigned content be parallel in structure to the signed content. When reading a string and constructing objects, our library parses the header and dispatches the parser based on the "alg" parameter. > > And as Mike points out, alg:none has been in the spec as required to implement for ages now, and it hasn't caused the horrible security holes that people are predicting. > > -- Justin > > On 08/01/2013 07:23 AM, jose issue tracker wrote: >> #36: Algorithm "none" should be removed >> >> >> Comment (by <mailto:[email protected]> [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! >> > > _______________________________________________ > jose mailing list > <mailto:[email protected]> [email protected] > <https://www.ietf.org/mailman/listinfo/jose> https://www.ietf.org/mailman/listinfo/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
