Hi John, > On 30 Apr 2018, at 15:07, John Bradley <ve7...@ve7jtb.com> wrote: > > I lean towards letting new certificate thumbprints be defined someplace else. > > With SHA256, it is really second preimage resistance that we care about for a > certificate thumbprint, rather than simple collision resistance.
That’s not true if you consider a malicious client. If I can find any pair of certificates c1 and c2 such that SHA256(c1) == SHA256(c2) then I can present c1 to the AS when I request an access token and later present c2 to the protected resource when I use it. I don’t know if there is an actual practical attack based on this, but a successful attack would violate the security goal implied by the draft: that that requests made to the protected resource "MUST be made […] using the same certificate that was used for mutual TLS at the token endpoint.” NB: this is obviously easier if the client gets to choose its own client_id, as it can find the colliding certificates and then sign up with whatever subject ended up in c1. > > MD5 failed quite badly with chosen prefix collision attacks against > certificates (Thanks to some X.509 extensions). > SHA1 has also been shown to be vulnerable to a PDF chosen prefix attack > (http://shattered.io) > > The reason NIST pushed for development of SHA3 was concern that a preimage > attack might eventually be found agains the SHA2 family of hash algorithms. > > While SHA512 may have double the number of bytes it may not help much against > a SHA2 preimage attack,. (Some papers suggest that the double word size of > SHA512 it may be more vulnerable than SHA256 to some attacks) This is really something where the input of a cryptographer would be welcome. As far as I am aware, the collision resistance of SHA-256 is still considered at around the 128-bit level, while it is considered at around the 256-bit level for SHA-512. Absent a total break of SHA2, it is likely that SHA-512 will remain at a higher security level than SHA-256 even if both are weakened by cryptanalytic advances. They are based on the same algorithm, with different parameters and word/block sizes. > > It is currently believed that SHA256 has 256 bits of second preimage > strength. That could always turn out to be wrong as SHA2 has some > similarities to SHA1, and yes post quantum that is reduced to 128bits. > > To have a safe future option we would probably want to go with SHA3-512. > However I don’t see that getting much traction in the near term. SHA3 is also slower than SHA2 in software. > > Practical things people should do run more along the lines of: > 1: Put at least 64 bits of entropy into the certificate serial number if > using self signed or a local CA. Commercial CA need to do that now. > 2: Rotate certificates on a regular basis, using a registered JWKS URI > > My concern is that people will see a bigger number and decide it is better if > we define it in the spec. > We may be getting people to do additional work and increasing token size > without a good reason by putting it in the spec directly. I’m not sure why this is a concern. As previously pointed out, SHA-512 is often *faster* than SHA-256, and an extra 32 bytes doesn’t seem worth worrying about. [snip] — Neil _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
