Thanks for the clarification Michael, I was actually wrongly assuming that the client has to propose the method. If the server can do that, then it is relative risk free to support additional algorithms on the client side (and ignore a challenge if it requests disabled algorithm (this would include md5 default for absent attribute)).
Did not know the WWW-Authenticate header does that. Still I would Seperate the md5 deprecation from the implementation of alternative algorithms to make a larger cut-over window (maybe even schedule it in the Oracle crypto roadmap) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: Michael McMahon <michael.x.mcma...@oracle.com> Gesendet: Friday, March 4, 2022 4:07:49 PM An: Bernd Eckenfels <e...@zusammenkunft.net>; net-dev@openjdk.java.net <net-dev@openjdk.java.net> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default Bernd, If I understand you correctly, there is no negotiation at this level. Once Digest is selected, it's up to the server to choose the algorithm and then the client can either accept it or else reject it and the whole request fails then. It's true that with this change, if the server proposes MD5 by default, then the request will fail. But, that's the point of the change, and the compatibility impact is considered in the related CSR. In that case, either the server needs to change or else the system property to re-enable MD5 must be set. I'd like to try out (for the next review round) the idea of establishing the default "insecure" protocols as a fixed security property (including MD5 and SHA-1) and then provide a settable system or networking property to override that. Thanks Michael On 04/03/2022 14:03, Bernd Eckenfels wrote: Hello, While I like the idea of the user having to explicitely specify the rexenabled legacy algorithms (as opposed to removing the defaultsdisabled) it is not the style the other algorithm policies in JCE work - so it might be confusing. But, more critically I would separate the enabling/implementing of new algorithms from disabling old ones. Especially since there needs to be changes on the server side first. (And I wonder if this can be negotiated anyway?). So why not start with a “provide new DIGEST Mechanisms” change? Having said that, would it need to start out with disabled new mechanisms so the update won’t change the behavior? (If there is no negotiation?) Gruss Bernd -- http://bernd.eckenfels.net ________________________________ Von: net-dev <net-dev-r...@openjdk.java.net><mailto:net-dev-r...@openjdk.java.net> im Auftrag von Michael McMahon <micha...@openjdk.java.net><mailto:micha...@openjdk.java.net> Gesendet: Friday, March 4, 2022 1:33:06 PM An: net-dev@openjdk.java.net<mailto:net-dev@openjdk.java.net> <net-dev@openjdk.java.net><mailto:net-dev@openjdk.java.net> Betreff: Re: RFR: 8281561: Disable http DIGEST mechanism with MD5 by default On Fri, 4 Mar 2022 09:37:21 GMT, Michael McMahon <micha...@openjdk.org><mailto:micha...@openjdk.org> wrote: Hi, Could I get the following change reviewed please, which is to disable the MD5 message digest algorithm by default in the HTTP Digest authentication mechanism? The algorithm can be opted into by setting a new system property "http.auth.digest.reEnabledAlgs" to include the value MD5. The change also updates the Digest authentication implementation to use some of the more secure features defined in RFC7616, such as username hashing and additional digest algorithms like SHA256 and SHA512-256. - Michael I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames="" I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name. Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point. So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in. I considered that and implemented it that way at the start, but what you would end up with then is users running their code with something like: -DdisabledAlgNames="" I find that style leads to a much less explicit "opting in" than by making the user explicitly identify the deprecated algorithm by name. Right - but it would also allow users to opt-in to disable more algorithms by listing them in the property In practical terms, the only other likely candidate there is SHA-1. If that weren't the case, I'd disagree with your point. So, maybe, we could have a 2nd net property with the default disabled algorithms and in net.properties we identify MD5 only for now. Users could add to that list if they want or even specify it on the command line. I think it's potentially confusing, but maybe there is a case for adding to the disabled list. I need to think about a way to do this without subvertng the point about making the user explicitly opt in. Thinking about it again, I wonder if we should just deprecate SHA-1 at the same time. I think there will be less compatibility impact than with MD5, and it's basically broken as well. I don't see a reason to opt out of other algorithms at this time. ------------- PR: https://git.openjdk.java.net/jdk/pull/7688
