Do you consider the people who are implementing the JWT specification to be novice or expert cryptography users? The problem is much more likely to occur with novice users of the system. The problem is also much more likely to occur after it is out in the real world and is protecting real and valuable assets than when it is just starting out. After all DNS had no real problems for the first umpteen years before people decided that attacking DNS was a worthwhile endeavor.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Justin Richer > Sent: Monday, August 19, 2013 9:30 AM > To: jose issue tracker > Cc: [email protected]; [email protected]; [email protected]; draft-ietf-jose- > [email protected] > Subject: Re: [jose] #36: Algorithm "none" should be removed > > 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 [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 > [email protected] > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
