Given that JWT can mandate that the none algorithm be required, I believe that it should be possible to lower the requirements level on the none algorithm from MUST to SHOULD or similar.
The required algorithms for JWT do not have to be the required algorithms for the JOSE documents. Jim From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Tuesday, August 20, 2013 1:37 PM To: Anthony Nadalin; Richard Barnes; Karen ODonoghue Cc: George Fletcher; jose issue tracker; [email protected]; John Bradley; Justin Richer; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed +1 Exactly what I was going to say! _____ From: Anthony Nadalin Sent: 8/20/2013 11:49 AM To: Richard Barnes; Karen ODonoghue Cc: George Fletcher; Mike Jones; jose issue tracker; [email protected]; John Bradley; Justin Richer; [email protected] Subject: RE: [jose] #36: Algorithm "none" should be removed I don't find the text objectionable but I find the concept/proposal objectionable, as I don't see the need for this since there is already a working solution and with the option that EKR proposed make this a manageable option as this is how we limit cipher suites today with application that need to be FIPS compliant. From: [email protected] [mailto:[email protected]] On Behalf Of Richard Barnes Sent: Tuesday, August 20, 2013 11:44 AM To: Karen ODonoghue Cc: George Fletcher; Mike Jones; jose issue tracker; [email protected]; John Bradley; Justin Richer; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed I have already posted proposed text for Option 2 (defining a new, two-component, one-dot, no-crypto syntax) <http://trac.tools.ietf.org/wg/jose/trac/attachment/ticket/36/ALG-NONE.patch > Would be interested in whether anyone finds that text objectionable. On Tue, Aug 20, 2013 at 2:41 PM, Karen O'Donoghue <[email protected]> wrote: This is perhaps a tiny nit, but I heard you take an action to write proposed text for discussion by the working group. I think this is an issue that needs to be resolved by a concrete set of agreed upon steps and actual text before interim action is taken to modify the documents. Karen On 8/20/13 1:33 PM, Mike Jones wrote: Please permit me add a couple more points to the summary: - Ekr suggested the possibility of having libraries, by default, not accept "none" unless called in a way in which the application indicates that it is acceptable. Mike agreed to take an action item to add this text to the document as a step towards resolving the issue in a way that addresses the concerns expressed about the possibility of downgrade attacks. - Tony and John pointed out that the issue being discussed is more general than just "none" - it's really the issue of what algorithms are acceptable to the application. They said that applications could pass in a list of acceptable algorithms, which is more general than special-casing "none". - Mike pointed out that people are likely to use general JOSE libraries processing all formats (JWS, JWE, unsigned) and so whether the wire format of an unsigned object looks like JWS (as it does now) or something else, libraries would still need to facilitate applications being written safely, as all kinds of objects can be processed by these libraries, independent of the wire format choice. Thus, the defense against downgrade attacks needs to happen in the library interface design, as ekr suggested. -- Mike From: Richard Barnes [mailto:[email protected]] Sent: Tuesday, August 20, 2013 7:33 AM To: George Fletcher Cc: Justin Richer; John Bradley; Mike Jones; jose issue tracker; [email protected]; [email protected] Subject: Re: [jose] #36: Algorithm "none" should be removed If I may summarize the call: -- There was agreement that we should define a "header + data" format, with no cryptographic protection -- There was disagreement on whether that unprotected format should be part of JWS, or something separate. Two options were proposed: 1. Use JWS, but require that implementations MUST NOT accept "none" unless explicitly directed to by an application 2. Define a new format, distinct from JWS, that just has header and payload (no signature). In the compact format, this would just have two dot-separated components. -- It was observed that either one of these options causes work for existing implementations. Option 1 causes them to expose API surface that may not be there now (to specify acceptable algorithms). Option 2 requires a change to parsing. On Tue, Aug 20, 2013 at 10:09 AM, George Fletcher <[email protected]> wrote: On 8/20/13 9:49 AM, Justin Richer wrote: On 08/19/2013 05:46 PM, Richard Barnes wrote: [snip] 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. -- Justin +1 And to take it even a bit further. There will come a time in the future when HS256 is deemed to be insecure and SHOULD NOT be used because it's been hacked/compromised. At that point in time, all the implementations will have to have a way to not allow alg:256. Hence there could be no security difference between alg:hs256 and alg:none at some point in the future. I realize I missed the call last night so maybe this is all mute:) Thanks, George _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
