Additional confirmation methods can be easily defined outside of this draft. That said, I think those two in particular are pretty straightforward to add (well-known algorithms that are widely available) so it might make sense to just toss them in now? I think it’s fine either way.
— Justin > On Apr 19, 2018, at 12:23 PM, Brian Campbell <bcampb...@pingidentity.com> > wrote: > > Okay, so I retract the idea of metadata indicating the hash alg/cnf method > (based on John pointing out that it doesn't really make sense). > > That still leaves the question of whether or not to define additional > confirmation methods in this document (and if so, what they would be though > x5t#S384 and x5t#S512 seem the most likely). > > There's some reasonable rational for both adding one or two new hash alg > confirmation methods in the doc now vs. sticking with just SHA256 for now. > I'll note again that the doc doesn't preclude using or later defining other > confirmation methods. > > I'm kind of on the fence about it, to be honest. But that doesn't really > matter because the draft should reflect rough WG consensus. So I'm looking to > get a rough gauge of rough consensus. At this point there's one comment out > of WGLC asking for additional confirmation method(s). I don't think that > makes for consensus. But I'd ask others from the WG to chime in, if > appropriate, to help me better gauge consensus. > > On Fri, Apr 13, 2018 at 4:49 AM, Neil Madden <neil.mad...@forgerock.com > <mailto:neil.mad...@forgerock.com>> wrote: > I’m not particularly wedded to SHA-512, just that it should be possible to > use something else. At the moment, the draft seems pretty wedded to SHA-256. > SHA-512 may be overkill, but it is fast (faster than SHA-256 on many 64-bit > machines) and provides a very wide security margin against any future crypto > advances (quantum or otherwise). I’d also be happy with SHA-384, SHA3-512, > Blake2 etc but SHA-512 seems pretty widely available. > > I don’t think short-lived access tokens is a help if the likelihood is that > certs will be reused for many access tokens. > > Public Web PKI certs tend to only use SHA-256 as it has broad support, and I > gather there were some compatibility issues with SHA-512 certs in TLS. There > are a handful of SHA-384 certs - e.g., the Comodo CA certs for > https://home.cern/ <https://home.cern/> are signed with SHA-384 (although > with RSA-2048, which NSA estimates at only ~112-bit security). SHA-512 is > used on some internal networks where there is more control over components > being used, which is also where people are mostly likely to care about > security beyond 128-bit level (eg government internal networks). > > By the way, I just mentioned quantum attacks as an example of something that > might weaken the hash in future. Obviously, quantum attacks completely > destroy RSA, ECDSA etc, so SHA-512 would not solve this on its own, but it > provides a considerable margin to hedge against future quantum *or classical* > advances while allowing the paranoid to pick a stronger security level now.. > We have customers that ask for 256-bit AES already. > > (I also misremembered the quantum attack - “Serious Cryptography” by Aumasson > tells me the best known quantum attack against collision resistance is > O(2^n/3) - so ~2^85 for SHA-256 but also needs O(2^85) space so is > impractical. I don’t know if that is the last word though). > > As for SHA-1, doesn’t that prove the point? SHA-1 is pretty broken now with > practical collisions having been demonstrated. The kind of attacks on CA > certs demonstrated for MD5 [1] are probably not too far off for SHA-1 now. As > far as I am aware, we’re nowhere near those kinds of attacks on SHA-256, but > I’d prefer that there was a backup plan in place already rather than waiting > to see (and waiting for everyone to have hard-coded SHA-256 everywhere). > > Now I have to get back to my daughter’s birthday party… :-) > > [1] http://www.win.tue.nl/hashclash/rogue-ca/ > <http://www.win.tue.nl/hashclash/rogue-ca/> > > Neil > > > On Thursday, Apr 12, 2018 at 10:07 pm, John Bradley <ve7...@ve7jtb.com > <mailto:ve7...@ve7jtb.com>> wrote: > 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 > > <mailto: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. > > > > 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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
