The WG discusses RS meta-data as part of one of Dick’s proposals. I am unclear on who is going to work on it in what draft.
If the client is doing mtls to both the Token endpoint and RS the information in the confirmation method is not relevant to the client as long as the AS and RS are in agreement like with most tokens. The hash on the certificate and length of the signing key are equally or more vulnerable to any sort of attack. At least with AT the tokens are not long lived. Doing anything better than SHA256 only makes sense if the cert is signed by something stronger like SHA512 with a 2048bit RSA key. That seems sort of unlikely in the near term. I prefer to wait to see what general fix is proposed before we jump the gun with a bandade for a small part of the overall problem. People are typically using SHA1 fingerprints. We added SHA256 for JWT and got push back on that as overkill. I don’t think this is the correct place to be deciding this. We could say that if new thumbprints are defined the AS and RS can decide to use them as necessary. That is sort of the situation we have now. The correct solution may be a thousand rounds of PBKDF2 or something like that to make finding collisions more difficult rather than longer hashes. John B. > On Apr 12, 2018, at 5:20 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > That's true about it being opaque to the client. I was thinking of client > metadata (config or registration) as a way for the AS to decide if to bind > the AT to a cert. And moving from a boolean to a conf method as an extension > of that. It would be more meaningful in RS discovery, if there was such a > thing. > > I don’t know that SHA512 would be the best choice either but it is something > that is stronger and could be included now. If there's consensus to do more > than SHA256 in this doc. > > > > On Thu, Apr 12, 2018 at 1:52 PM, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > Inline > > Snip > >> >> >> 12. The use of only SHA-256 fingerprints means that the security strength of >> the sender-constrained access tokens is limited by the collision resistance >> of SHA-256 - roughly “128-bit security" - without a new specification for a >> new thumbprint algorithm. An implication of this is that is is fairly >> pointless for the protected resource TLS stack to ever negotiate cipher >> suites/keys with a higher level of security. In more crystal ball territory, >> if a practical quantum computer becomes a possibility within the lifetime of >> this spec, then the expected collision resistance of SHA-256 would drop >> quadratically, allowing an attacker to find a colliding certificate in ~2^64 >> effort. If we are going to pick just one thumbprint hash algorithm, I would >> prefer we pick SHA-512. >> >> The idea behind haveing just one thumbprint hash algorithm was to keep >> things simple. And SHA-256 seems good enough for the reasonably foreseeable >> future (and space aware). Also a new little spec to register a different >> hash algorithm, should the need arise, didn't seem particularity onerous. >> >> That was the thinking anyway. Maybe it is too short sighted though? >> >> I do think SHA-256 should stay regardless. >> >> But the draft could also define SHA-512 (and maybe others). What do you and >> WG folks think about that? >> >> *** Yes please. >> >> It would probably then be useful for the metadata in §3.3 and §3.4 to change >> from just boolean values to something to convey what hash alg/cnf method the >> client expects and the list of what the server supports. That's maybe >> something that should be done anyway. That'd be a breaking change to the >> metadata. But there's already another potential breaking change identified >> earlier in this message. So maybe it's worth doing... >> >> How do folks feel about making this kind of change? >> >> > The confirmation method is opaque to the client. I don’t think adding hash > algs to discovery will really help. > The AS selection needs to be based on what the RS can support. > > If anyplace it should be in RS discovery. > > As a practical matter you art going to find a client certificate with more > than a SHA256 hash anytime in the near future. > So for a short lived access token 128bits of collision resistance is quite > good. We are going to have issues with certificates long before this > becomes a problem. > > SHA256 is appropriate for AES128 256bit elliptic curves and 3072bit RSA keys, > but again that is over the long term. > We are using short lived access tokens. People should rotate the certificate > more often than once a year if this is a real issue. > > I am not against new hash for the fingerprint, but I also don’t know that > SHA512 would be the best choice if we are concerned about quantum crypto > resistance. That is a issue beyond mtls and should be addressed by CFRG etc. > > Regards > John B. > > > > > CONFIDENTIALITY NOTICE: This email may contain confidential and privileged > material for the sole use of the intended recipient(s). Any review, use, > distribution or disclosure by others is strictly prohibited. If you have > received this communication in error, please notify the sender immediately by > e-mail and delete the message and any file attachments from your computer. > Thank you.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
