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?
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.
--
kivinen(_at_)iki(_dot_)fi