On Tue, Aug 20, 2013 at 9:49 AM, Justin Richer <[email protected]> wrote:
> > On 08/19/2013 05:46 PM, Richard Barnes wrote: > > > > > On Mon, Aug 19, 2013 at 5:27 PM, Justin Richer <[email protected]> wrote: > >> On 08/19/2013 04:17 PM, Richard Barnes wrote: >> >> On Mon, Aug 19, 2013 at 3:48 PM, John Bradley <[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/ca58ff0ece35243aa6546583dffcd236dcea26d2/src/main/java/com/nimbusds/jwt/JWTParser.java?at=master >> > >> >> >> Uh, no, it doesn't. In fact, it throws an error: >> >> java.text.ParseException: Invalid serialized plain/JWS/JWE object: >> Missing second delimiter >> at com.nimbusds.jose.JOSEObject.split(JOSEObject.java:222) >> at com.nimbusds.jwt.PlainJWT.parse(PlainJWT.java:99) >> at com.nimbusds.jwt.JWTParser.parse(JWTParser.java:61) >> >> >> >> From that very code you should be able to see that it plucks off the >> header and looks for the algorithm value, creating a "PlainJWT" object if >> alg=none. >> > > Ah, the risks of reading code. I stand corrected. At least the > top-level parsing works, so you could just adapt the PlainJWT.parse() > method. > > > So that would be the very definition of a breaking change. > I realize we're trying to avoid those, but security risks are worth breaking change. And as Vladimir observed, it's not a huge change; in fact, it's something that some implementations are basically doing already. > >> 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 >> >> >> I am too, but from the opposite end -- why is it so important for you to >> delete that single "." character? >> > > It's important that something that is not signed is does not pass JWS > validation. If something unsigned is ever accepted as a valid JWS, then > there's a huge downgrade risk. > > > I think that's a red herring. It's the same downgrade risk if someone > sends alg:rot13 and your app doesn't want to accept that "signature" > either. A JWS with alg:none should pass *only* if the signature field is > empty, full stop. > If I'm an attacker, it it any harder for me to strip the signature field than it is to change the "alg" field? Plus, as several people observed on the call yesterday, there's a huge difference between downgrading from "secure" to "less-secure" and downgrading from "secure" to "completely unprotected". --Richard > > -- Justin > > > > > >> >> >> -- Justin >> >> >> >> >> >> >> >> >>> >>> John B. >>> >>> On 2013-08-19, at 12:30 PM, Justin Richer <[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 [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
