Re: [secdir] Secdir review of draft-ietf-jose-json-web-signature-31

[Richard Barnes <[e-mail]>]

On Tue, Sep 16, 2014 at 4:51 AM, Tero Kivinen <[e-mail]> wrote:

> Richard Barnes writes:
> >>>     1) "alg" and Protected Header
> >>>
> >>>     Question: Shouldn't the "alg" header parameter be protected by
> >>>     the signature, i.e. wouldn't it make sense to say MUST be in
> >>>     the "Protected Header"?
> >>>
> >>>     I think the draft needs text saying something about the
> >>>     situation where "alg" is not in "Protected Header" in the
> >>>     security sections section. I.e. either say, that it has been
> >>>     analyzed that there is no problem even when the "alg" is not
> >>>     protected, and reference to such analysis, or otherwise add
> >>>     text/warning that it MUST/SHOULD be in the "Protected Header".
> >>>     I do not know enough about the proposed signature algorithms
> >>>     to know which one is true, especially as there might be new
> >>>     algorithms in the future.
> >>>
> >>     Richard Barnes, do you want to answer this one?  You were the
> >>     primary advocate for allowing the algorithm to be unprotected
> >>     in the JSON Serialization.
> >>
> >>     As I recall, the motivation had to do with the fact that, by
> >>     default, CMS does not protect the algorithm (although it was
> >>     later extended to enable it to be protected).  Some others in
> >>     the working group thought that having unprotected algorithms
> >>     was a bad idea, in line with your comment above.
> >
> > The only need for protection of the "alg" value is to prevent algorithm
> > substitution attacks, as discussed in RFC 6211.
> > https://tools.ietf.org/html/rfc6211
> >
> > These attacks are fairly limited in their applicability, since they
> require
> > that:
> >  * The attacker is able to compute an input that is valid for the
> signature
> > using a different, weaker algorithm
> >  * The attacker's input is valid according to whatever application rules
> are
> > being applied
> >  * A relying party will accept the weaker algorithm
> >
> > Given all those criteria, it seems reasonable that some signers
> > might regard algorithm substitution attacks as an acceptable risk.
>
> Perhaps, but is there benefits for leaving the alg without protection?
>

Simplicity (if you omit protected headers altogether), and compatibility
with other signed things.  In the sense that you could transform one of
them into a JWS without re-signing.  This would apply, for example, to an
X.509 certificate -- just parse the outer SEQUENCE, and re-assemble into a
JWS with the tbsCertificate as payload.  Same security properties that
X.509 already has.

It's also completely unnecessary for PKCS#1 signatures, which are the
dominant use case today.

In general, I'm opposed to protocols baking in more application-specific
logic than they need to.  The point of JOSE is to describe the
cryptographic operation that was performed, and carry the relevant bits
around.  Its job is not to fix all the weaknesses that every algorithm
has.

--Richard



> > For example, in an application that set explicit minimum algorithm
> > requirements (e.g., SHA-3 only!), there may be no risk of a relying
> > party accepting the weaker algorithm.  Or the application payload
> > might have low enough entropy that it's impossible to find a valid
> > forged input.
> >
> > And if an application is concerned about algorithm substitution
> > attacks, it can protect itself by including the algorithm in the
> > payload, as X.509 does.
>
> Having this kind of options which might or might not have security is
> usually bad. So I would suggest that unless there is use case or real
> reason why the alg should NOT be protected all the time, make it
> protected always.
>
> > I would be happy to have some advisory text in the security
> > considerations, but I don't think this rises to the level of
> > SHOULD/MUST.
>
> I hate to be there in ten years, when someone finds out problems with
> this prorotocol, as someone decided to add some new algorithms, and
> someone then decided to use the feature include, i.e. having alg
> unprotected, and then the combination suddenly causes problems...
>
> So if there is no reason to keep it that way, I would be much more
> happy to say that it must be protected always.
> --
> [e-mail]
>