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] <[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 [email protected]https://www.ietf.org/mailman/listinfo/jose > > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
