Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

[Neil Madden <[e-mail]>]

Hi John,

> On 30 Apr 2018, at 15:07, John Bradley <[e-mail]> 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