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@xxxxxx