The threat model changed.

If I'm using HTTP, and my traffic is unencrypted, there isn't a vulnerability.

If I'm using HTTPS, and my traffic is unencrypted or can be decrypted, there's a serious vulnerability!

This CVE does not allow decryption (or non-encryption) of HTTPS.

The point is the expectation not meeting reality - nothing about that specific technology.

Just strange to use HTTP for comparison when the actual problem works just fine.

If I'm connecting to WiFi normally, and expecting that I can be tracked, there isn't a vulnerability.

If I'm connecting to WiFi using this privacy feature, and expecting NOT to be trackable, yet someone is still able to track me, there is a serious vulnerability!

That's what comparisons and analogies are for.

The HTTP comparison helped me understand the issue.

Pre 14 phones leak MAC to all people around, post 14 phones only expose it inside encrypted network phone was allowed to connect.

I would argue you’re almost right, the two considerations are intent (if you say something is true and it is not true, that is a vulnerability) and real world use (if the site accepts usernames and passwords, and is unencrypted, and there is some impact to a breach or credential theft, there is a vulnerability).

It implies that other devices that are not supposed to report their MAC, but do, deserve a high CVE as well.

This has to do with a bug seriously compromising a feature. It does not reflect the overall security rating of the entire device. If I have a one-way data diode sending telemetry from the flight controller to a passenger's entertainment console, it works as intended - which is why they put in a layer1 one-way diode. When you have a feature, you use that feature for a scenario where it is useful.

If the flight controller data diode has a second fiber and allows it to be hacked from a passenger seat entertainment center, that is a high severity. It does not mean every network switch has a high severity security issue, because we don't put those into flight controllers that hook up to entertainment centers.

Let's do a car example. If I rent a Uhaul to move my piano, and it splits in half from the weight, this is a serious malfunction. It does not mean the mini-coop croaking from a piano loaded on it's hood is also a serious malfunction.

Let's do a food example. If I put an empty metal frying pan on a stove and it bursts my house into flames, this is a serious problem with the frying pan. If I put it in the microwave and it does that, that's not a problem with the frying pan.

It's best to avoid reading much meaning into CVE scores. So much depends on the perennial question "what's your threat model?"

This question and many more can be applied on using CVSSv3. So a pentester doesn't have to use CVE scores as holy bible in their report. A risk assessment can be worked upon by those who are going to consider the recommendations in the report.

I don't understand this. By that logic you could go from HTTP to a new but buggy and flawed HTTPS (when that was in its infancy) and rather than that being considered a vulnerability, you could say "Well, everyone else is just using HTTP so they deserve a CVE too..."

Should we not mark insecure protocols with tremendous numbers of CVEs?

No, because the advertised additional security may cause people to do things that they would not otherwise have done had they not falsely believed the security claims on the newer protocol.

Because after iOS 14, users have an expectation of being more private when they weren't.

You can apply this anywhere:

FDE being broken.

Zero days being used on journalists.

Security theater post 9/11.

Your 4 y.o. choking on a toy deemed unsafe for age 0-3.

Security people always use this crazy risk matrix where if it’s easy to reproduce and affects a lot of people, it becomes high severity even if there is essentially no real world risk. I guess it makes them look better when they can show all the “high” severity issues they found.