That text is fine with me. I would prefer the SHOULD be a MUST, but I could imagine some interface like RealJWSVerifier that takes things from HTTP, vs. NotReallyAJWSVerifierDangerWillRobinson from HTTPS.
Though it does highlight the crazy contortions we're having to go through to get "none" right, rather than just defining a separate syntax. On Thu, Sep 5, 2013 at 11:55 AM, Matt Miller (mamille2) <[email protected]>wrote: > I agree with the intent, but I'm not very comfortable with the actual > text. It reads too much like software interface design, and I'd rather > avoid telling people exactly how to write their software. > > My suggested change (still makes me squeamish, but I can live with it): > > """ > Implementations that support unsigned JWS objects (i.e., the "alg" value > "none") MUST NOT accept such objects as valid unless the application > specifies that it is acceptable for a specific object to be unsigned. > Implementations MUST NOT accept unsigned JWS objects by default. For > example, > the "verify" method of a hypothetical JWS software library might have a > boolean "acceptUnsigned" parameter (which defaults to "false") that > indicates > "none" is an acceptable "alg" value. > > In order to mitigate downgrade attacks, applications MUST NOT indicate > acceptance of unsigned JWS objects at a global level, and SHOULD specify > acceptance on a per-object basis. For example, suppose an application > accepts > JWS objects over two channels, (1) HTTP and (2) HTTPS with client > authentication. It requires a JWS signature on objects received over HTTP, > but accepts unsigned JWS objects over HTTPS. If the application globally > indicates that "none" is acceptable, then an attacker could provide it > with an > unsigned object over HTTP and still have that object considered valid. > Instead, the application needs indicate acceptance of "none" for each > object > received over HTTPS (e.g., by setting "acceptUnsigned" to "true" for the > hypothetical JWS software library above), but not for each object received > over > HTTP. > """ > > > - m&m > > Matt Miller < [email protected] > > Cisco Systems, Inc. > > On Sep 5, 2013, at 9:10 AM, Richard Barnes <[email protected]> wrote: > > > Thinking on this a little more, it seems like it would be simpler to > state > > this just as an "allow unsigned" flag, rather than a more general > > "acceptable algorithms" set. That way we don't have to worry about all > the > > downgrade scenarios when you have "none" along with something else. > > > > """ > > Implementations that support unsigned JWS objects (i.e., the "alg" value > > "none") MUST NOT accept such objects as valid unless the application > > specifies that it is acceptable for a specific object to be unsigned. > For > > example, the "verify" method of a JWS library might have a boolean > > "acceptUnsigned" parameter that would indicate that "none" is an > acceptable > > "alg" value. > > > > Applications MUST specify this flag on a per-object basis, since > otherwise > > they will be vulnerable to downgrade attacks. For example, suppose an > > application accepts JWS objects over two channels, (1) HTTP and (2) HTTPS > > with client authentication. It requires a JWS signature on objects > received > > over HTTP, but accepts unsigned JWS objects over HTTPS. If the > application > > sets a global setting that "none" is acceptable, then an attacker could > > provide it with an unsigned object over HTTP and still have that object > > considered valid. Instead, the application needs to set the > > "acceptUnsigned" flag to "false" for each object received over HTTP, and > to > > "true" for each object received over HTTPS. > > """ > > > > This makes the equivalence between the "separate object" and "constrained > > verify" cases a lot clearer. On the one hand, you would have > > "jose.somethingNotVerify(JWP)", and on the other hand, you would have > > "jose.verify(JWP, acceptUnsigned=True)". > > > > --Richard > > > > > > > > > > On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones <[email protected] > >wrote: > > > >> I took an action item during the last call to write text along the lines > >> suggested by ekr about applications and "alg":"none". I propose that > the > >> following text be included:**** > >> > >> ** ** > >> > >> It is RECOMMENDED that libraries provide applications a means of > >> specifying the list of acceptable algorithms used in a JWS object in a > way > >> that causes inputs using algorithms outside the specified set to be > >> rejected. In particular, it is intended for applications to use this > >> mechanism to exclude accepting inputs using "alg":"none" in security > >> contexts where non-integrity protected inputs are not acceptable.**** > >> > >> ** ** > >> > >> Feedback/proposed wording refinements welcomed.**** > >> > >> ** ** > >> > >> -- > Mike*** > >> * > >> > >> ** ** > >> > >> _______________________________________________ > >> jose mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > >> > >> > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
