I had an interesting discussion with security experts inside Sun. The topic was OAuth and the way digital signature is defined there. One issue that was raised is the fact that (beside PLAINTEXT) only HMAC-SHA1 and RSA-SHA1 are defined in the specification when NIST recommends dropping those in place of SHA2 algorithms…
Why not using RSA-SHA256 at minimum and recommend to switch to the winner of the SHA3 competition whenever practical (granted, it’s gonna take a while…)?

Judging from the discussion on the OAuth mailing list prior to the release of the core spec, it seems that the main concern was the lack of support for, say, SHA256. This to me is a bit surprising for 2 reasons:
(1) I believe when creating a specification we should not settle for the lowest denominator but rather aim at a level of security that will last a reasonable amount time (between the time to implement and the time real deployments happen, security weaknesses will only get worse). This is even more important for specs, like OAuth, that seem promised to a bright & long future.
(2) It seems to me that RSA-SHA256 is available in most languages used in web development (Java, Perl, Php, python…).
So what am I missing?

Another issue is the lack of mandate for at least one signature mechanism and making the other ones optional. This certainly could cause interoperability issues as 2 implementations might be compliant to the specification and still not able to interoperate (i.e. if the consumer only supports a signature method that happens to be different from the one supported by the provider).

Hopefully, these issues will be addressed during the work done at IETF, now that the spec is headed there. More to come as I deep dive in OAuth and discuss this out with the OAuth experts.

Advertisements