It's probably worth noting that this idea that whenever you verify an object, you have to specify a set of acceptable algorithms, is a completely new one in the space of crypto APIs. Every API out there that takes a signed object (cert or SignedData) just tells you whether the signature on the object validates, leaving it to the application to check the algorithm.
CAPI/X.509: < http://msdn.microsoft.com/en-us/library/windows/desktop/aa377166(v=vs.85).aspx > BouncyCastle/X.509: < http://bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/CertificateVerifyer.html > OpenSSL/CMS: <http://www.openssl.org/docs/crypto/CMS_verify.html> OpenSSL/X.509: <http://www.openssl.org/docs/crypto/X509_verify_cert.html> NSS/CMS: < http://mxr.mozilla.org/security/source/security/nss/lib/certhigh/certvfy.c#98 > NSS/X.509: < https://developer.mozilla.org/en-US/docs/NSS_Certificate_Functions#CERT_VerifyCert > In *none* of these APIs is it the job of the verification library to do algorithm checking. This is yet another way that layering violations in the OpenID use case are being used to force the crypto layer to deal with things the application layer should be doing. It's just bad, insecure design. It's not worth it to avoid a minor parser change. --Richard On Tue, Aug 20, 2013 at 2:50 PM, Anthony Nadalin <[email protected]>wrote: > 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] <[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
