[MZMegaZone]

Yeah, I've been with F5 since 2010 - gotta love those old PortMasters though, Livingston was good times, until Lucent took over. I was there 95-98.

I don't know what else there is to say really. The QUIC/HTTP/3 vuln was found in NGINX OSS, which is also the basis for the commercial NGINX+ product. We looked at the issue and decided that, by our disclosure policies, we needed to assign a CVE and make a disclosure. And I was firmly in that camp - my personal motto is "Our customers cannot make informed decisions about their networks if we do not inform them." I fight for the users.

Anyway, Maxim did not seem to agree with that position. There wasn't much debate about it - the policy was pretty clear and we said we're issuing a CVE. And this is the result as near I can tell.

Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.

[kelnos]

Oof. Presumably Dounin had other gripes about the company that had been building up? This seems like a pretty weird catalyst for a fork. Feels more like this was the last straw among many.

I get that CVEs have been politicized and weaponized by a bunch of people, but it seems weird to object that strenuously to something like this.

[dgacmu]

Oh my god, the Internet is such a small place. Good to hear you're doing well - we interacted a bit when I was running an ISP in the 90s as well. (Dave Andersen, then at ArosNet -- we ran a lot of PM2.5e and then PM3s).

And appreciate the clarification about the CVE disagreement.

[MZMegaZone]

Those were great times. I learned a hell of a lot working at Livingston, because we had to. We were basically a startup selling to ISPs right as the Internet exploded and we grew like crazy. Suddenly we're doing ISDN BRI/PRI, OSPF, BGP, PCM modems, releasing chassis products (PM-4)... Real fun times, always something new happening. I even ended up our corporate webmaster since I'd been playing with web tech for a few years and thought it'd be a good idea if we had a site. Quite a way to jumpstart a career.

And the customers were, by and large, great.

[rlaager]

I don't know much about this situation, but from what I've read, you were clearly in the right. It doesn't matter if the feature is in optional/experimental code. If it's there and has a vulnerability, give it a CVE. The customers/users can choose how much they care about it from there.

> Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.

I recently did exactly that when a vendor refused to obtain a CVE themselves. In my case, I was doing it as part of an effort to educate the vendor on how CVEs worked.

[conartist6]

You bring up NGINX+, a commercial product with a CVE reporting policy, but just from reading the docs on it it doesn't support QUIC or HTTP/3. So I guess I can see why the maintainer would be mad about a commercial policy applying to noncommercial work in the absence of any real threat.

[MZMegaZone]

https://www.nginx.com/blog/quic-http3-support-openssl-nginx/

I know there are other mentions - it's been in the commercial product since R30, hence the CVE.

[mholt]

> Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.

Even if third parties can file CVEs, do you think it hits different when the parent organization decides to do so against the developer's wishes? Why do he and F5 view the bugs differently? It sounds like the fork decision was motivated less by the actual CVEs and more about how the decision was negotiated (or not at all).

(PS. Thanks for participating in the discussion.)

[kayfox]

Personally, I think its more honest if the parent org does not try to contest a CVE being assigned to a legitimate issue. If a CNA gets a report of a vulnerability in code, even if its an uncommon configuration, they should be assigning a CVE to it and disclosing it. The entire point of the CVE program is to identify with a precise identifier, the CVE, each vulnerability that was shipped in code that is generally available.

Based on my observation of various NGINX forums and mailing lists, the HTTP/3 feature, while experimental, is seeing adoption by the leading edge of web applications, so I don't think it could be argued that its not being slowly rolled into production in places.