On the call today, I was asked to generate a proposal for what it would look like to support a "header+payload" format that was not JWS. I have attached a patch to JWS and JWA to ISSUE-36
tl;dr: Define JSON Web Payload, which is JWS without a signature and MUST NOT be accepted by verify() <http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch > On Mon, Aug 19, 2013 at 6:32 PM, Jim Schaad <[email protected]> wrote: > 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
