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> im Auftrag von Michael McMahon <micha...@openjdk.java.net> Gesendet: Friday, March 4, 2022 1:33:06 PM An: net-dev@openjdk.java.net <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> 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
