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

[Neil Madden <[e-mail]>]

JOSE and many other specs have allowed algorithms to be specified at multiple security levels: a baseline 128-bit level, and then usually 192- and 256-bit levels too. It seems odd that a draft that is ostensibly for high security assurance environments would choose to only specify the lowest acceptable security level, especially when the 256-bit level has essentially negligible overhead. (OK, ~60 bytes additional overhead in a JWT - I’d be surprised if that was a deal breaker though).

Still, if the consensus of the WG is that this is not worth it, then I don’t want to delay the draft any further. I can always submit a 2 line RFC in future to add a SHA-512 confirmation method.

— Neil

> On 30 Apr 2018, at 23:58, John Bradley <[e-mail]> wrote:
> 
> We allow for new thumbprint algorithms to be defined and used with this spec.
> I think that we all agree that is a good thing.
> 
> The question is if we should define them here or as part of JWT/CWT based on broader demand.
> 
> Including them in this document may be a distraction in my opinion.   There is no attack against SHA256 with a short duration token/key (days) that is better solved by using a long duration token/key (years) with a longer hash.
> 
> That said it woiulden't like me.  I just think it will distract people in the wrong direction.
> 
> John B.
> 
>> On Apr 30, 2018, at 7:23 PM, Neil Madden <[e-mail]> wrote:
>> 
>> Responses inline again. 
>> 
>> On Mon, 30 Apr 2018 at 19:44, John Bradley <[e-mail]> wrote:
>> Inline.
>> 
>> 
>>> On Apr 30, 2018, at 12:57 PM, Neil Madden <[e-mail]> wrote:
>>> 
>>> 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.
>>> 
>> 
>> Both C1 and C2 need to be valid certificates, so not just any collision will do.  
>> 
>> That doesn’t help much. There’s still enough you can vary in a certificate to generate collisions. 
>> 
>> If the client produces C1 and C2 and has the private keys for them, I have a hard time seeing what advantage it could get by having colliding certificate hashes.
>> 
>> Me too. But if the security goal is proof of possession, then this attack (assuming practical collisions) would break that goal. 
>> 
>> 
>> If the AS is trusting a CA, the attacker producing a certificate that matches the hash of another certificate so that it seems like the fake certificate was issued by the CA, is an attack that worked on MD5 given some predictability.  That is why we now have entropy requirements for certificate serial numbers, that reduce known prefix attacks.
>> 
>> The draft allows for self-signed certificates. 
>> 
>> Second-preimage Resistance is being computationaly infusible to find a second preimage that has the same output as the first preimage.   The second preimage strength for SHA256 is 201-256bits and collision resistance strength is 128 bits.  See Appendix A of https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-107r1.pdf if you want to understand the relationship between message length and second Preimage resistance.
>> 
>> RFC 4270 is old but still has some relevant info. https://tools.ietf.org/html/rfc4270
>> 
>> Think of the confirmation method as the out of band integrity check for the certificate that is presented in the TLS session.
>> 
>> This is all largely irrelevant. 
>> 
>>>> 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.
>>> 
>> SHA512 uses double words and more rounds, true.  It also has more rounds broken by known attacks than SHA256 https://en.wikipedia.org/wiki/SHA-2.. So it is slightly more complex than doubling the output size doubles the strength.
>> 
>> SHA-512 also has more rounds (80) than SHA-256 (64), so still has more rounds left to go...
>> 
>> 
>>>> 
>>>> 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.
>> Yes roughly half the speed in software but generally faster in hardware.  
>> 
>> I am not necessarily arguing for SHA3, rather I think this issue is larger than this spec and selecting alternate hashing algorithms for security should be separate from this spec.
>> 
>> I am for agility, but I don’t want to accidentally have people doing something that is just theatre.
>> 
>> Rotating certificates, and having the lifetime of a certificates validity is as useful as doubling the hash size. 
>> 
>> Why not allow both? 
>> 
>> 
>> I don’t think the confirmation hash length is the weakest link.
>> 
>> Shouldn’t we allow all the parts to be as strong as possible?
>> 
>> 
>> John B.
>> 
>>> 
>>>> 
>>>> 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
>> — Neil
>