Re: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?
On 27/05/2020 15:33, Tomas Mraz wrote: > On Wed, 2020-05-27 at 14:16 +, Dr. Matthias St. Pierre wrote: >>> IMO it seems appropriate to have an OMC vote on this topic (or >>> should it >>> be OTC?). Possible wording: >> >> Personally, I would prefer if technical questions would by default be >> discussed (and voted on) >> by the OTC, unless an OMC member explicitly puts in his veto and >> claims that higher level >> strategical interests of the OpenSSL project are affected. >> >> But according to the current wording of the bylaws, I would say it is >> a 'feature requirement' and >> requires an OMC vote: > > I do not understand this to be a 'feature requirement' - IMO if this > was a 'feature requirement' it would mean that OMC decides that > something must be implemented in such and such way that the OpenSSL 3.0 > does this and that as a feature. But we do not do that for every > feature that is being added to master. So I do not even think this > requires any formal vote, unless someone from OTC or OMC calls for it > explicitly. > > Of course it is kind-of API break but again I do not think every API > break in OpenSSL 3.0 was voted upon by OMC. > > I mean I am definitely not against having a vote if someone feels it > should be done but if nobody requires it, I do not think it would be a > violation of anything if this is merged without a vote. I think there should be a vote. IMO such a significant break should be done as a result of a positive decision and not on the basis of a very small number of people approving a PR. I can see arguments both ways for it being an OTC vote or an OMC vote. To an extent it is purely a technical decision i.e. to answer the question: "does it technically make sense to make this change?" It also has a business requirements aspect to it i.e. to answer the question "would this have such a significant impact on the OpenSSL user base that, regardless of its technical merits, we still shouldn't do it?" On reflection though I'm not sure that the technical merits of this are particularly controversial. So I'm thinking that the OMC is still the right forum for this. However if someone else thinks that the *technical* arguments are controversial there is no reason why we couldn't have an OTC vote *as well*. I won't be proposing that though. Matt
RE: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?
> I mean I am definitely not against having a vote if someone feels it > should be done but if nobody requires it, I do not think it would be a > violation of anything if this is merged without a vote. Tomáš I dont't mind following your viewpoint at all, and if the OMC thinks the same, that's fine. Also, I agree that an OTC/OMC discussion does not automatically have to be resolved by an OTC/OMC vote. Maybe my original post was a bit misleading. The main motivation behind it was my impression that we tend to start many technical discussions with a general discussion about whether it should be discussed/decided by the OMC or the OTC. Matthias
Re: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?
On Wed, 2020-05-27 at 14:16 +, Dr. Matthias St. Pierre wrote: > > IMO it seems appropriate to have an OMC vote on this topic (or > > should it > > be OTC?). Possible wording: > > Personally, I would prefer if technical questions would by default be > discussed (and voted on) > by the OTC, unless an OMC member explicitly puts in his veto and > claims that higher level > strategical interests of the OpenSSL project are affected. > > But according to the current wording of the bylaws, I would say it is > a 'feature requirement' and > requires an OMC vote: I do not understand this to be a 'feature requirement' - IMO if this was a 'feature requirement' it would mean that OMC decides that something must be implemented in such and such way that the OpenSSL 3.0 does this and that as a feature. But we do not do that for every feature that is being added to master. So I do not even think this requires any formal vote, unless someone from OTC or OMC calls for it explicitly. Of course it is kind-of API break but again I do not think every API break in OpenSSL 3.0 was voted upon by OMC. I mean I am definitely not against having a vote if someone feels it should be done but if nobody requires it, I do not think it would be a violation of anything if this is merged without a vote. > > The OMC: > > > > * makes all decisions regarding management and strategic direction > > of the project; including: > > - business requirements; > > - feature requirements; > > - platform requirements; > > - roadmap requirements and priority; > > - end-of-life decisions; > > - release timing and requirement decisions; > > Matthias > -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
RE: Reducing the security bits for MD5 and SHA1 in TLS - OTC or OMC vote?
> IMO it seems appropriate to have an OMC vote on this topic (or should it > be OTC?). Possible wording: Personally, I would prefer if technical questions would by default be discussed (and voted on) by the OTC, unless an OMC member explicitly puts in his veto and claims that higher level strategical interests of the OpenSSL project are affected. But according to the current wording of the bylaws, I would say it is a 'feature requirement' and requires an OMC vote: > The OMC: > > * makes all decisions regarding management and strategic direction of the > project; including: > - business requirements; > - feature requirements; > - platform requirements; > - roadmap requirements and priority; > - end-of-life decisions; > - release timing and requirement decisions; Matthias
Re: Reducing the security bits for MD5 and SHA1 in TLS
If you do this, you should add a FAQ (in addition to NEWS) explaining it.
Re: Reducing the security bits for MD5 and SHA1 in TLS
On Wed, 2020-05-27 at 12:14 +0100, Matt Caswell wrote: > PR 10787 proposed to reduce the number of security bits for MD5 and > SHA1 > in TLS (master branch only, i.e. OpenSSL 3.0): > > https://github.com/openssl/openssl/pull/10787 > > This would have the impact of meaning that TLS < 1.2 would not be > available in the default security level of 1. You would have to set > the > security level to 0. > > In my mind this feels like the right thing to do. The security bit > calculations should reflect reality, and if that means that TLS < 1.2 > no > longer meets the policy for security level 1, then that is just the > security level doing its job. However this *is* a significant > breaking > change and worthy of discussion. Since OpenSSL 3.0 is a major release > it > seems that now is the right time to make such changes. > > IMO it seems appropriate to have an OMC vote on this topic (or should > it > be OTC?). Possible wording: > > "The TLS security bit values for MD5, MD5_SHA1 and SHA1 should be set > to > 39, 67 and 65 respectively in OpenSSL 3.0. Consequently TLS < 1.2 > will > be disallowed in the default security level" > > Thoughts? +1 I do not even think this is too much controversial to do in a major release. The only possibly controversial thing is the handling of the certificates signed with SHA1 and especially rejecting the client certificates on the client side before they are sent to the server. That is the: https://github.com/openssl/openssl/issues/11702 -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Reducing the security bits for MD5 and SHA1 in TLS
PR 10787 proposed to reduce the number of security bits for MD5 and SHA1 in TLS (master branch only, i.e. OpenSSL 3.0): https://github.com/openssl/openssl/pull/10787 This would have the impact of meaning that TLS < 1.2 would not be available in the default security level of 1. You would have to set the security level to 0. In my mind this feels like the right thing to do. The security bit calculations should reflect reality, and if that means that TLS < 1.2 no longer meets the policy for security level 1, then that is just the security level doing its job. However this *is* a significant breaking change and worthy of discussion. Since OpenSSL 3.0 is a major release it seems that now is the right time to make such changes. IMO it seems appropriate to have an OMC vote on this topic (or should it be OTC?). Possible wording: "The TLS security bit values for MD5, MD5_SHA1 and SHA1 should be set to 39, 67 and 65 respectively in OpenSSL 3.0. Consequently TLS < 1.2 will be disallowed in the default security level" Thoughts? Matt
